(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-10-13
(45)【発行日】2023-10-23
(54)【発明の名称】映像表示プログラム
(51)【国際特許分類】
A63F 13/86 20140101AFI20231016BHJP
A63F 13/428 20140101ALI20231016BHJP
A63F 13/55 20140101ALI20231016BHJP
A63F 13/30 20140101ALI20231016BHJP
A63F 13/49 20140101ALI20231016BHJP
A63F 13/424 20140101ALI20231016BHJP
A63F 13/52 20140101ALI20231016BHJP
A63F 13/53 20140101ALI20231016BHJP
H04N 21/431 20110101ALI20231016BHJP
H04N 21/435 20110101ALI20231016BHJP
【FI】
A63F13/86
A63F13/428
A63F13/55
A63F13/30
A63F13/49
A63F13/424
A63F13/52
A63F13/53
H04N21/431
H04N21/435
(21)【出願番号】P 2020057857
(22)【出願日】2020-03-27
【審査請求日】2022-01-20
(73)【特許権者】
【識別番号】509070463
【氏名又は名称】株式会社コロプラ
(74)【代理人】
【識別番号】100142365
【氏名又は名称】白井 宏紀
(72)【発明者】
【氏名】福重 潤哉
(72)【発明者】
【氏名】山本 順也
(72)【発明者】
【氏名】猪俣 篤
【審査官】相川 俊
(56)【参考文献】
【文献】特開2020-044135(JP,A)
【文献】特開2005-323827(JP,A)
【文献】特開2013-138893(JP,A)
【文献】特開2016-093364(JP,A)
【文献】特開2017-148319(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
A63F 13/00 - 13/98
H04N 21/431
H04N 21/435
G06F 13/00
(57)【特許請求の範囲】
【請求項1】
プロセッサ、メモリ、および表示部を備える端末装置において実行される
映像表示プログラムであって、
前記プロセッサに、
演者の動きに応じてリアルタイムに動作するキャラクタを含む仮想空間の映像を表示するためのデータであってライブ配信されるデータを受信するステップと、
受信したデータに基づいて前記仮想空間の映像を表示するステップとを実行させ、
前記データは、ライブ配信を構成する第1のパートの終了に対応する第1データと、前記第1のパートに続く第2のパートの開始に対応する第2データとを含み、
前記表示するステップは、
前記第1データに基づいて前記第1のパートを終了するときに当該第1のパートの仮想空間の映像から予め定められている特定映像に切り替えて表示し、
前記特定映像表示中において前記第2データを受信したときには、前記特定映像を表示していた表示時間にかかわらず、当該特定映像から前記第2のパートの仮想空間の映像に切り替えて表示する、
映像表示プログラム。
【請求項2】
前記第2データは、前記第1データを配信した後の所定契機成立時に配信されるデータであり、
前記表示するステップは、前記表示時間が前記第1データ配信から前記第2データ配信までに要した時間に達していないときでも、前記特定映像を表示しているときに前記第2データを受信したときには前記特定映像から前記第2のパートの仮想空間の映像に切り替えて表示する、請求項1に記載の
映像表示プログラム。
【請求項3】
前記表示するステップは、前記データがライブ配信されてから当該データに基づいて前記仮想空間の映像を表示するまでに特定時間以上を要する状況であるか否かを判定し、当該特定時間以上を要する状況である場合には前記特定映像に切り替えて表示した後、当該特定映像表示中に受信したデータに基づいて前記仮想空間の映像に切り替えて表示する、請求項1または請求項2に記載の
映像表示プログラム。
【請求項4】
前記特定時間は、前記第1データ配信から当該第2データ配信までに要する時間に応じて予め定められている時間である、請求項3に記載の
映像表示プログラム。
【請求項5】
前記データは、演者が入力した音声およびモーションに応じた音声データおよびモーションデータを含み、
前記表示するステップは、受信したデータのうち音声データの再生に合わせて、当該音声データを基準にして当該音声データに対応するモーションデータを再生して、前記仮想空間内において動作するキャラクタを表示し、
前記第1のパートの終了を特定するための情報、および、前記第2のパートの開始を特定するための情報は、前記データのうちの前記音声データに含まれる、請求項1~請求項4のいずれかに記載の
映像表示プログラム。
【請求項6】
前記ライブ配信を構成するパートには、前記端末装置を所有するユーザが参加可能となるゲームが行われる特定パートを含み、
前記表示するステップは、前記特定パートの途中から前記ライブ配信の視聴を開始するときには、受信したデータに基づいて当該特定パートの前記仮想空間の映像を表示するとともに、所定タイミングまで待機を促すための待機情報を表示する、請求項1~請求項5のいずれかに記載の
映像表示プログラム。
【請求項7】
前記表示するステップは、前記特定パートの途中から前記ライブ配信の視聴を開始するタイミングが当該特定パートのうちの特定期間中であるときには前記待機情報を表示しない一方、非特定期間中であるときには前記待機情報を表示する、請求項6に記載の
映像表示プログラム。
【請求項8】
前記非特定期間は、前記ゲームに参加するとユーザが不利となり得るとして予め定められている期間である、請求項7に記載の
映像表示プログラム。
【請求項9】
前記表示するステップは、前記特定パートの途中から前記ライブ配信の視聴を開始するときには、前記特定映像を表示した後、受信したデータに基づいて前記仮想空間の映像に切り替えて表示する、請求項6~請求項8のいずれかに記載の
映像表示プログラム。
【請求項10】
前記特定映像は、前記表示部の全表示領域を用いて表示される映像である、請求項1~請求項9のいずれかに記載の
映像表示プログラム。
【請求項11】
前記特定映像は、終了する前記第1のパートの種類または当該特定映像表示後に開始する前記第2のパートの種類に応じた映像を含む、請求項1~請求項10のいずれかに記載の
映像表示プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、映像表示プログラムに関する。
【背景技術】
【0002】
近年、インターネットなどを介して配信される動画を、スマートフォンなどの端末装置を用いて視聴するユーザが増加している。このような動画を端末装置において視聴する際には、端末装置毎の通信において突発的あるいは一時的に生じた不具合などの影響により、端末装置間において再生される動画にズレ(遅延)が生じる。このような端末装置間における動画のズレを防止するために、あるチャプターに対応する動画を再生しているときには、再生開始から予め定められている実行時間が経過したときに、当該チャプターに対応する動画が途中(終了していないとき)であっても次のチャプターに対応する動画の再生を強制的に開始することにより端末装置間において同期を図るものがあった(特許文献1)。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかし、特許文献1に記載の配信システムでは、遅れている端末装置においては動画が途中で突然終了してしまい、なおかつ唐突に次のチャプター動画が開始されてしまう。このため、配信品質が粗悪であるといった印象や配信内容に違和感をユーザに抱かせてしまう虞があり、改善の余地があった。
【0005】
本発明は、かかる実情に鑑み考え出されたものであり、その目的は、配信品質に対する印象を極力低下させずかつ配信内容に違和感を生じさせてしまうことを極力防止できる、映像表示プログラムを提供することである。
【課題を解決するための手段】
【0006】
本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、および表示部を備える端末装置において実行される映像表示プログラムであって、プロセッサに、演者の動きに応じてリアルタイムに動作するキャラクタを含む仮想空間の映像を表示するためのデータであってライブ配信されるデータを受信するステップと、受信したデータに基づいて仮想空間の映像を表示するステップとを実行させ、データは、ライブ配信を構成する第1のパートの終了に対応する第1データと、第1のパートに続く第2のパートの開始に対応する第2データとを含み、表示するステップは、第1データに基づいて第1のパートを終了するときに第1のパートの仮想空間の映像から予め定められている特定映像に切り替えて表示し、特定映像表示中において第2データを受信したときには、特定映像を表示していた表示時間にかかわらず、特定映像から第2のパートの仮想空間の映像に切り替えて表示する。
【発明の効果】
【0007】
本発明によれば、配信品質に対する印象を極力低下させずかつ配信内容に違和感を生じさせてしまうことを極力防止できる。
【図面の簡単な説明】
【0008】
【
図1】ある実施の形態に従うシステムの概要の一例を示す図である。
【
図2】ある実施の形態に従うユーザ端末のハードウェア構成の一例を示すブロック図である。
【
図3】ある実施の形態に従うサーバのハードウェア構成の一例を示すブロック図である。
【
図4】ある実施の形態に従うゲームプレイ端末のハードウェア構成の一例を示すブロック図である。
【
図5】ある実施の形態に従う配信端末のハードウェア構成の一例を示すブロック図である。
【
図6】ある実施の形態に従うユーザ端末、サーバ、HMDセットの機能的構成の一例を示すブロック図である。
【
図7】ある実施の形態に従う配信端末の機能的構成の一例を示すブロック図である。
【
図8】ある実施の形態に従うユーザ端末およびゲームプレイ端末において実行される処理の一部を表すフローチャートである。
【
図9】ある実施の形態に従う、プレイヤに提供される仮想空間、および、プレイヤが視認する視界画像の一例を示す図である。
【
図10】ある実施の形態に従う、ユーザ端末のユーザに提供される仮想空間、および、該ユーザが視認する視界画像の一例を示す図である。
【
図11】ユーザ端末のユーザが視認する視界画像の他の例を示す図である。
【
図12】ユーザ端末のユーザが視認する視界画像のさらに別の例を示す図である。
【
図13】ある実施の形態に従うゲームプレイ端末において実行される処理の一部を表すフローチャートである。
【
図14】ある実施の形態に従うユーザ端末において実行される処理の一部を表すフローチャートである。
【
図15】ある実施の形態に従うサーバにおいて実行される処理の一部を表すフローチャートである。
【
図16】ある実施の形態に従う、ゲームに参加したユーザのリストの一具体例を示す図である。
【
図17】ある実施の形態に従う配信端末において実行される処理の一部を表すフローチャートである。
【
図18】ある実施の形態に従う配信端末に表示される画面の一具体例を示す図である。
【
図19】ある実施の形態に従う配信端末に表示される画面の他の具体例を示す図である。
【
図20】ある実施の形態に従う、プレイヤによる音声入力の一具体例を示す図である。
【
図21】ある実施の形態に従う配信端末に表示される画面のさらなる別の具体例と、動作指図データの配信の概要とを示す図である。
【
図22】ある実施の形態に従う、プレイヤによる音声入力の他の具体例を示す図である。
【
図23】ある実施の形態に従う配信端末に表示される画面のさらなる別の具体例と、動作指図データの配信の概要とを示す図である。
【
図24】ある実施形態に従うゲームプレイ端末からユーザ端末へのゲーム進行情報の送信の概要を示す図である。
【
図25】ある実施の形態に従うユーザ端末において実行される処理の一部を表すフローチャートである。
【
図28】ライブ配信中のユーザ端末のタッチスクリーンにおける表示例を説明するための図である。
【
図29】複数のユーザ端末間における映像のズレを説明するためのタイミングチャートである。
【
図30】(A)は、ジャンケンゲームパートのうち一つの場面(例えば1回戦)が開始されてから結果報知までのゲーム進行に関して予め定められているスケジュール例を説明するための図であり、(B)~
図30(E)は、ライブ配信を途中から視聴した場合のユーザ端末のタッチスクリーンにおける表示例を説明するための図である。
【
図31】(A)はゲーム進行情報の構成の一例を示す図であり、(B)は音声データ、モーションデータ、仮想空間制御データの入出力タイミングの一例を示す図である。
【
図32】(A)は音声データ、モーションデータ、仮想空間制御データの入出力タイミングの他の例を示す図であり、(B)は音声データ、モーションデータ、仮想空間制御データの入出力タイミングのその他の一例を示す図である。
【発明を実施するための形態】
【0009】
本開示に係るシステムは、複数のユーザにゲームを提供するためのシステムである。以下、該システムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。
【0010】
<システム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(登録商標))等が挙げられる。
【0011】
(ゲームの概要)
本実施形態では、システム1によって提供されるゲーム(以下、本ゲーム)の一例として、ゲームプレイ端末300のユーザが主としてプレイするゲームを説明する。以下、ゲームプレイ端末300のユーザを、「プレイヤ」と称する。プレイヤ(演者)は、一例として、本ゲームに登場するキャラクタを操作することにより、ゲームを進行させる。また、本ゲームにおいて、ユーザ端末100のユーザは、プレイヤによるゲームの進行を支援する役割を担う。本ゲームの詳細については後述する。なお、システム1によって提供されるゲームは、複数のユーザが参加するゲームであればよく、この例に限定されない。
【0012】
(ゲームプレイ端末300)
ゲームプレイ端末300は、プレイヤによる入力操作に応じてゲームを進行させる。また、ゲームプレイ端末300は、プレイヤのゲームプレイにより生成された情報(以下、ゲーム進行情報)を、順次、サーバ200にリアルタイムで配信する。
【0013】
(サーバ200)
サーバ200は、ゲームプレイ端末300からリアルタイムに受信したゲーム進行情報(第2データ)を、ユーザ端末100に送信する。また、サーバ200は、ユーザ端末100、ゲームプレイ端末300、および配信端末400の間の各種情報の送受信を仲介する。
【0014】
(配信端末400)
配信端末400は、配信端末400のユーザによる入力操作に応じて、動作指図データ(第1データ)を生成し、サーバ200を介してユーザ端末100へ動作指図データを配信する。動作指図データとは、ユーザ端末100において動画を再生するためのデータであり、具体的には、動画に登場するキャラクタを動作させるためのデータである。
【0015】
本実施形態では、一例として、配信端末400のユーザは、本ゲームのプレイヤである。また、一例として、ユーザ端末100にて動作指図データに基づいて再生される動画は、プレイヤがゲームで操作したキャラクタが動作する動画である。「動作」とは、キャラクタの身体の少なくとも一部を動かすことであり、発話も含む。このため、本実施形態に係る動作指図データは、例えば、キャラクタに発話させるための音声データと、キャラクタの身体を動かすためのモーションデータとを含む。
【0016】
動作指図データは、一例として、本ゲームの終了後にユーザ端末100へ送信される。動作指図データ、および、該動作指図データに基づいて再生される動画の詳細については後述する。
【0017】
(ユーザ端末100)
ユーザ端末100は、ゲーム進行情報をリアルタイムに受信し、該情報を用いてゲーム画面を生成して表示する。換言すれば、ユーザ端末100は、リアルタイムレンダリングにより、プレイヤがプレイしているゲームのゲーム画面を再生する。これにより、ユーザ端末100のユーザは、プレイヤがゲームをプレイしながら視認しているゲーム画面と同一のゲーム画面を、プレイヤとほぼ同じタイミングで視認することができる。
【0018】
また、ユーザ端末100は、ユーザによる入力操作に応じて、プレイヤによるゲームの進行を支援するための情報を生成し、該情報を、サーバ200を介してゲームプレイ端末300へ送信する。該情報の詳細については後述する。
【0019】
また、ユーザ端末100は、配信端末400から動作指図データを受信し、該動作指図データを用いて動画(映像)を生成して再生する。換言すれば、ユーザ端末100は、動作指図データをレンダリングして再生する。
【0020】
<システム1のハードウェア構成>
図2は、ユーザ端末100のハードウェア構成を示す図である。
図3は、サーバ200のハードウェア構成を示す図である。
図4は、ゲームプレイ端末300のハードウェア構成を示す図である。
図5は、配信端末400のハードウェア構成を示す図である。
【0021】
(ユーザ端末100)
本実施形態では、一例として、ユーザ端末100がスマートフォンとして実現される例を説明するが、ユーザ端末100はスマートフォンに限定されない。例えば、ユーザ端末100はフィーチャーフォン、タブレット型コンピュータ、ラップトップ型コンピュータ(いわゆる、ノートパソコン)、または、デスクトップ型コンピュータなどとして実現されてもよい。また、ユーザ端末100は、ゲームプレイに適したゲーム装置であってもよい。
【0022】
ユーザ端末100は
図2に示すように、プロセッサ10と、メモリ11と、ストレージ12と、通信インターフェース(IF)13と、入出力IF14と、タッチスクリーン15(表示部)と、カメラ17と、測距センサ18とを備える。ユーザ端末100が備えるこれらの構成は、通信バスによって互いに電気的に接続される。なお、ユーザ端末100は、タッチスクリーン15に代えて、または、加えて、ユーザ端末100本体とは別に構成されたディスプレイ(表示部)を接続可能な入出力IF14を備えていてもよい。
【0023】
また、
図2に示すように、ユーザ端末100は、1つ以上のコントローラ1020と通信可能に構成されることとしてもよい。コントローラ1020は、例えば、Bluetooth(登録商標)等の通信規格に従って、ユーザ端末100と通信を確立する。コントローラ1020は、1つ以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末100へ送信する。また、コントローラ1020は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末100へ送信する。
【0024】
なお、ユーザ端末100がカメラ17および測距センサ18を備えることに代えて、または、加えて、コントローラ1020がカメラ17および測距センサ18を有していてもよい。
【0025】
ユーザ端末100は、例えばゲーム開始時に、コントローラ1020を使用するユーザに、該ユーザの名前またはログインID等のユーザ識別情報を、該コントローラ1020を介して入力させることが望ましい。これにより、ユーザ端末100は、コントローラ1020とユーザとを紐付けることが可能となり、受信した出力値の送信元(コントローラ1020)に基づいて、該出力値がどのユーザのものであるかを特定することができる。
【0026】
ユーザ端末100が複数のコントローラ1020と通信する場合、各コントローラ1020を各ユーザが把持することで、ネットワーク2を介してサーバ200などの他の装置と通信せずに、該1台のユーザ端末100でマルチプレイを実現することができる。また、各ユーザ端末100が無線LAN(Local Area Network)規格等の無線規格により互いに通信接続する(サーバ200を介さずに通信接続する)ことで、複数台のユーザ端末100によりローカルでマルチプレイを実現することもできる。1台のユーザ端末100によりローカルで上述のマルチプレイを実現する場合、ユーザ端末100は、さらに、サーバ200が備える後述する種々の機能の少なくとも一部を備えていてもよい。また、複数のユーザ端末100によりローカルで上述のマルチプレイを実現する場合、複数のユーザ端末100は、サーバ200が備える後述する種々の機能を分散して備えていてもよい。
【0027】
なお、ローカルで上述のマルチプレイを実現する場合であっても、ユーザ端末100はサーバ200と通信を行ってもよい。例えば、あるゲームにおける成績または勝敗等のプレイ結果を示す情報と、ユーザ識別情報とを対応付けてサーバ200に送信してもよい。
【0028】
また、コントローラ1020は、ユーザ端末100に着脱可能な構成であるとしてもよい。この場合、ユーザ端末100の筐体における少なくともいずれかの面に、コントローラ1020との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末100とコントローラ1020とが結合している場合は、ユーザ端末100とコントローラ1020とは、有線を介して信号を送受信する。
【0029】
図2に示すように、ユーザ端末100は、外部のメモリカード等の記憶媒体1030の装着を、入出力IF14を介して受け付けてもよい。これにより、ユーザ端末100は、記憶媒体1030に記録されるプログラム及びデータを読み込むことができる。記憶媒体1030に記録されるプログラムは、例えばゲームプログラムである。
【0030】
ユーザ端末100は、サーバ200等の外部の装置と通信することにより取得したゲームプログラムをユーザ端末100のメモリ11に記憶してもよいし、記憶媒体1030から読み込むことにより取得したゲームプログラムをメモリ11に記憶してもよい。
【0031】
以上で説明したとおり、ユーザ端末100は、該ユーザ端末100に対して情報を入力する機構の一例として、通信IF13、入出力IF14、タッチスクリーン15、カメラ17、および、測距センサ18を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。
【0032】
例えば、操作部が、カメラ17および測距センサ18の少なくともいずれか一方で構成される場合、該操作部が、ユーザ端末100の近傍の物体1010を検出し、当該物体の検出結果から入力操作を特定する。一例として、物体1010としてのユーザの手、予め定められた形状のマーカーなどが検出され、検出結果として得られた物体1010の色、形状、動き、または、種類などに基づいて入力操作が特定される。より具体的には、ユーザ端末100は、カメラ17の撮影画像からユーザの手が検出された場合、該撮影画像に基づき検出されるジェスチャ(ユーザの手の一連の動き)を、ユーザの入力操作として特定し、受け付ける。なお、撮影画像は静止画であっても動画であってもよい。
【0033】
あるいは、操作部がタッチスクリーン15で構成される場合、ユーザ端末100は、タッチスクリーン15の入力部151に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信IF13で構成される場合、ユーザ端末100は、コントローラ1020から送信される信号(例えば、出力値)をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力IF14で構成される場合、該入出力IF14と接続されるコントローラ1020とは異なる入力装置(図示せず)から出力される信号をユーザの入力操作として特定し、受け付ける。
【0034】
(サーバ200)
サーバ200は、一例として、ワークステーションまたはパーソナルコンピュータなどの汎用コンピュータであってよい。サーバ200は、プロセッサ20と、メモリ21と、ストレージ22と、通信IF23と、入出力IF24とを備える。サーバ200が備えるこれらの構成は、通信バスによって互いに電気的に接続される。
【0035】
(ゲームプレイ端末300)
ゲームプレイ端末300は、一例として、パーソナルコンピュータなどの汎用コンピュータであってよい。ゲームプレイ端末300は、プロセッサ30と、メモリ31と、ストレージ32と、通信IF33と、入出力IF34とを備える。ゲームプレイ端末300が備えるこれらの構成は、通信バスによって互いに電気的に接続される。
【0036】
図4に示すように、本実施形態に係るゲームプレイ端末300は、一例として、HMD(Head Mounted Display)セット1000に含まれる。つまり、HMDセット1000が、システム1に含まれていると表現することができ、また、プレイヤは、HMDセット1000を用いてゲームをプレイすると表現することもできる。なお、プレイヤがゲームをプレイするための装置は、HMDセット1000に限定されない。一例として、該装置は、プレイヤにゲームを仮想体験させることが可能な装置であればよい。また、該装置は、スマートフォン、フィーチャーフォン、タブレット型コンピュータ、ラップトップ型コンピュータ(いわゆる、ノートパソコン)、または、デスクトップ型コンピュータなどとして実現されてもよい。また、該装置は、ゲームプレイに適したゲーム装置であってもよい。
【0037】
HMDセット1000は、ゲームプレイ端末300の他、HMD500、HMDセンサ510、モーションセンサ520、ディスプレイ530、コントローラ540を備える。HMD500は、モニタ51と、注視センサ52と、第1カメラ53と、第2カメラ54と、マイク55と、スピーカ56とを含む。コントローラ540は、モーションセンサ520を含み得る。
【0038】
HMD500は、プレイヤの頭部に装着され、動作中に仮想空間をプレイヤに提供し得る。より具体的には、HMD500は、右目用の画像および左目用の画像をモニタ51にそれぞれ表示する。プレイヤの各目がそれぞれの画像を視認すると、プレイヤは、両目の視差に基づき当該画像を3次元画像として認識し得る。HMD500は、モニタを備える所謂ヘッドマウントディスプレイと、スマートフォンその他のモニタを有する端末を装着可能なヘッドマウント機器のいずれをも含み得る。
【0039】
モニタ51は、例えば、非透過型の表示装置として実現される。ある局面において、モニタ51は、プレイヤの両目の前方に位置するようにHMD500の本体に配置されている。したがって、プレイヤは、モニタ51に表示される3次元画像を視認すると、仮想空間に没入することができる。ある局面において、仮想空間は、例えば、背景、プレイヤが操作可能なオブジェクト、プレイヤが選択可能なメニューの画像を含む。ある局面において、モニタ51は、所謂スマートフォンその他の情報表示端末が備える液晶モニタまたは有機EL(Electro Luminescence)モニタとして実現され得る。
【0040】
別の局面において、モニタ51は、透過型の表示装置として実現され得る。この場合、HMD500は、
図1に示されるようにプレイヤの目を覆う密閉型ではなく、メガネ型のような開放型であり得る。透過型のモニタ51は、その透過率を調整することにより、一時的に非透過型の表示装置として構成可能であってもよい。モニタ51は、仮想空間を構成する画像の一部と、現実空間とを同時に表示する構成を含んでいてもよい。例えば、モニタ51は、HMD500に搭載されたカメラで撮影した現実空間の画像を表示してもよいし、一部の透過率を高く設定することにより現実空間を視認可能にしてもよい。
【0041】
ある局面において、モニタ51は、右目用の画像を表示するためのサブモニタと、左目用の画像を表示するためのサブモニタとを含み得る。別の局面において、モニタ51は、右目用の画像と左目用の画像とを一体として表示する構成であってもよい。この場合、モニタ51は、高速シャッタを含む。高速シャッタは、画像がいずれか一方の目にのみ認識されるように、右目用の画像と左目用の画像とを交互に表示可能に作動する。
【0042】
ある局面において、HMD500は、図示せぬ複数の光源を含む。各光源は例えば、赤外線を発するLED(Light Emitting Diode)により実現される。HMDセンサ510は、HMD500の動きを検出するためのポジショントラッキング機能を有する。より具体的には、HMDセンサ510は、HMD500が発する複数の赤外線を読み取り、現実空間内におけるHMD500の位置および傾きを検出する。
【0043】
別の局面において、HMDセンサ510は、カメラにより実現されてもよい。この場合、HMDセンサ510は、カメラから出力されるHMD500の画像情報を用いて、画像解析処理を実行することにより、HMD500の位置および傾きを検出することができる。
【0044】
別の局面において、HMD500は、位置検出器として、HMDセンサ510の代わりに、あるいはHMDセンサ510に加えてセンサ(不図示)を備えてもよい。HMD500は、該センサを用いて、HMD500自身の位置および傾きを検出し得る。例えば、該センサが角速度センサ、地磁気センサ、あるいは加速度センサである場合、HMD500は、HMDセンサ510の代わりに、これらの各センサのいずれかを用いて、自身の位置および傾きを検出し得る。一例として、HMD500に備えられたセンサが角速度センサである場合、角速度センサは、現実空間におけるHMD500の3軸周りの角速度を経時的に検出する。HMD500は、各角速度に基づいて、HMD500の3軸周りの角度の時間的変化を算出し、さらに、角度の時間的変化に基づいて、HMD500の傾きを算出する。
【0045】
注視センサ52は、プレイヤの右目および左目の視線が向けられる方向を検出する。つまり、注視センサ52は、プレイヤの視線を検出する。視線の方向の検出は、例えば、公知のアイトラッキング機能によって実現される。注視センサ52は、当該アイトラッキング機能を有するセンサにより実現される。ある局面において、注視センサ52は、右目用のセンサおよび左目用のセンサを含むことが好ましい。注視センサ52は、例えば、プレイヤの右目および左目に赤外光を照射するとともに、照射光に対する角膜および虹彩からの反射光を受けることにより各眼球の回転角を検出するセンサであってもよい。注視センサ52は、検出した各回転角に基づいて、プレイヤの視線を検知することができる。
【0046】
第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台のカメラでプレイヤの顔を撮影するようにしてもよい。
【0047】
マイク55は、プレイヤの発話を音声信号(電気信号)に変換してゲームプレイ端末300に出力する。スピーカ56は、音声信号を音声に変換してプレイヤに出力する。別の局面において、HMD500は、スピーカ56に替えてイヤホンを含み得る。
【0048】
コントローラ540は、有線または無線によりゲームプレイ端末300に接続されている。コントローラ540は、プレイヤからゲームプレイ端末300への命令の入力を受け付ける。ある局面において、コントローラ540は、プレイヤによって把持可能に構成される。別の局面において、コントローラ540は、プレイヤの身体あるいは衣類の一部に装着可能に構成される。さらに別の局面において、コントローラ540は、ゲームプレイ端末300から送信される信号に基づいて、振動、音、光のうちの少なくともいずれかを出力するように構成されてもよい。さらに別の局面において、コントローラ540は、プレイヤから、仮想空間に配置されるオブジェクトの位置や動きを制御するための操作を受け付ける。
【0049】
ある局面において、コントローラ540は、複数の光源を含む。各光源は例えば、赤外線を発するLEDにより実現される。HMDセンサ510は、ポジショントラッキング機能を有する。この場合、HMDセンサ510は、コントローラ540が発する複数の赤外線を読み取り、現実空間内におけるコントローラ540の位置および傾きを検出する。別の局面において、HMDセンサ510は、カメラにより実現されてもよい。この場合、HMDセンサ510は、カメラから出力されるコントローラ540の画像情報を用いて、画像解析処理を実行することにより、コントローラ540の位置および傾きを検出することができる。
【0050】
モーションセンサ520は、ある局面において、プレイヤの手に取り付けられて、プレイヤの手の動きを検出する。例えば、モーションセンサ520は、手の回転速度、回転数等を検出する。検出された信号は、ゲームプレイ端末300に送られる。モーションセンサ520は、例えば、コントローラ540に設けられている。ある局面において、モーションセンサ520は、例えば、プレイヤに把持可能に構成されたコントローラ540に設けられている。別の局面において、現実空間における安全のため、コントローラ540は、手袋型のようにプレイヤの手に装着されることにより容易に飛んで行かないものに装着される。さらに別の局面において、プレイヤに装着されないセンサがプレイヤの手の動きを検出してもよい。例えば、プレイヤを撮影するカメラの信号が、プレイヤの動作を表わす信号として、ゲームプレイ端末300に入力されてもよい。モーションセンサ520とゲームプレイ端末300とは、一例として、無線により互いに接続される。無線の場合、通信形態は特に限られず、例えば、Bluetoothその他の公知の通信手法が用いられる。
【0051】
ディスプレイ530は、モニタ51に表示されている画像と同様の画像を表示する。これにより、HMD500を装着しているプレイヤ以外のユーザにもプレイヤと同様の画像を視聴させることができる。ディスプレイ530に表示される画像は、3次元画像である必要はなく、右目用の画像や左目用の画像であってもよい。ディスプレイ530としては、例えば、液晶ディスプレイや有機ELモニタなどが挙げられる。
【0052】
ゲームプレイ端末300は、HMD500の各部、コントローラ540、およびモーションセンサ520から取得した各種情報に基づいて、プレイヤの操作対象となるキャラクタを動作させ、ゲームを進行させる。ここでの「動作」には、身体の各部を動かすこと、姿勢を変えること、顔の表情を変えること、移動、発話、仮想空間に配置されたオブジェクトに触れたり、動かしたりすること、キャラクタが把持する武器、道具などを使用することなどが含まれる。すなわち、本ゲームでは、プレイヤが身体の各部を動かすことにより、キャラクタもプレイヤと同様に身体の各部を動かす。また、本ゲームでは、プレイヤが発話した内容をキャラクタが発話する。換言すれば、本ゲームにおいて、キャラクタは、プレイヤの分身としてふるまうアバターオブジェクトである。一例として、キャラクタの動作の少なくとも一部が、プレイヤによるコントローラ540に対する入力により実行されてもよい。
【0053】
本実施形態では、モーションセンサ520は、一例として、プレイヤの両手、プレイヤの両足、プレイヤの腰部、および、プレイヤの頭部に取り付けられる。プレイヤの両手に取り付けられるモーションセンサ520は、上述したとおり、コントローラ540に設けられていてもよい。また、プレイヤの頭部に取り付けられるモーションセンサ520は、HMD500に設けられていてもよい。モーションセンサ520は、さらに、ユーザの両肘や両膝に取り付けられてもよい。プレイヤに取り付けるモーションセンサ520の数を増やすことにより、プレイヤの動きをより正確にキャラクタに反映させることができる。
また、プレイヤは、モーションセンサ520を身体の各部に取り付けることに代えて、1以上のモーションセンサ520が取り付けられたスーツを着用してもよい。つまり、モーションキャプチャの方法は、モーションセンサ520を用いる例に限定されない。
【0054】
(配信端末400)
配信端末400は、スマートフォン、PDA(Personal Digital Assistant)、またはタブレット型コンピュータ等の携帯端末であってよい。また、配信端末400は、デスクトップパソコン等の、いわゆる据え置き型の端末であってもよい。
【0055】
配信端末400は、
図5に示すように、プロセッサ40と、メモリ41と、ストレージ42と、通信IF43と、入出力IF44と、タッチスクリーン45とを備える。なお、配信端末400は、タッチスクリーン45に代えて、または、加えて、配信端末400本体とは別に構成されたディスプレイ(表示部)を接続可能な入出力IF44を備えていてもよい。
【0056】
コントローラ1021は、1つ以上のボタン、レバー、スティック、ホイール等の物理的な入力機構を有していてもよい。コントローラ1021は、配信端末400の操作者(本実施形態ではプレイヤ)が、該入力機構に対して入力した入力操作に基づく出力値を配信端末400へ送信する。また、コントローラ1021は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値を配信端末400へ送信してもよい。上述の出力値は、通信IF43を介して配信端末400に受け付けられる。
【0057】
配信端末400は、カメラと、測距センサ(ともに不図示)とを備えていてもよい。配信端末400が備えることに代えて、または、加えて、コントローラ1021がカメラと、測距センサとを有してしてもよい。
【0058】
以上で説明したとおり、配信端末400は、該配信端末400に対して情報を入力する機構の一例として、通信IF43、入出力IF44、タッチスクリーン45を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。
【0059】
操作部がタッチスクリーン45で構成されている場合、配信端末400は、タッチスクリーン45の入力部451に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信IF43で構成される場合、配信端末400は、コントローラ1021から送信される信号(例えば、出力値)をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力IF44で構成される場合、配信端末400は、該入出力IF44と接続される入力装置(図示せず)から出力される信号をユーザの入力操作として特定し、受け付ける。
【0060】
<各装置のハードウェア構成要素>
プロセッサ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は、展開したプログラムを実行する。
【0061】
メモリ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がプログラムに従って動作している間に生成した各種データも一時的に記憶する。
【0062】
本実施形態において、プロセッサ10および30が実行するプログラムは、本ゲームのゲームプログラムであってもよい。本実施形態において、プロセッサ40が実行するプログラムは、動作指図データの配信を実現するための配信プログラムであってもよい。また、プロセッサ10は、さらに、動画の再生を実現するための視聴プログラムを実行してもよい。
【0063】
本実施形態において、プロセッサ20が実行するプログラムは、上述のゲームプログラム、配信プログラム、視聴プログラムの少なくとも何れかであってもよい。プロセッサ20は、ユーザ端末100、ゲームプレイ端末300、および配信端末400の少なくとも何れかからの要求等に応じて、ゲームプログラム、配信プログラム、視聴プログラムの少なくとも何れかを実行する。なお、配信プログラムと視聴プログラムは、並行して実行されてもよい。
【0064】
すなわち、ゲームプログラムは、ゲームをユーザ端末100、サーバ200、およびゲームプレイ端末300の協働により実現するプログラムであってもよい。配信プログラムは、動作指図データの配信を、サーバ200と配信端末400との協働により実現するプログラムであってもよい。視聴プログラムは、動画の再生を、ユーザ端末100とサーバ200との協働により実現するプログラムであってもよい。
【0065】
ストレージ12、22、32、42は補助記憶装置である。ストレージ12、22、32、42は、フラッシュメモリまたはHDD(Hard Disk Drive)等の記憶装置で構成される。ストレージ12、32には、例えば、ゲームに関する各種データが格納される。ストレージ42には、動作指図データの配信に関する各種データが格納される。また、ストレージ12には、動画の再生に関する各種データが格納される。ストレージ22には、ゲーム、動作指図データの配信、および動画の再生それぞれに関する各種データのうち、少なくとも一部が格納されてもよい。
【0066】
通信IF13、23、33、43は、それぞれ、ユーザ端末100、サーバ200、ゲームプレイ端末300、配信端末400における各種データの送受信を制御する。通信IF13、23、33、43は例えば、無線LAN(Local Area Network)を介する通信、有線LAN、無線LAN、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。
【0067】
入出力IF14、24、34、44は、それぞれ、ユーザ端末100、サーバ200、ゲームプレイ端末300、配信端末400がデータの入力を受け付けるため、また、データを出力するためのインターフェースである。入出力IF14、24、34、44は、USB(Universal Serial Bus)等を介してデータの入出力を行ってもよい。入出力IF14、24、34、44は、物理ボタン、カメラ、マイク、スピーカ、マウス、キーボード、ディスプレイ、スティック、レバーなどを含み得る。また、入出力IF14、24、34、44は、周辺機器との間でデータを送受信するための接続部を含み得る。
【0068】
タッチスクリーン15は、入力部151と表示部152(ディスプレイ)とを組み合わせた電子部品である。タッチスクリーン45は、入力部451と表示部452とを組み合わせた電子部品である。入力部151および451は、一例として、タッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部152および452は、例えば液晶ディスプレイ、または有機EL(Electro-Luminescence)ディスプレイ等によって構成される。
【0069】
入力部151および451は、入力面に対しユーザの操作(主にタッチ操作、スライド操作、スワイプ操作、およびタップ操作等の物理的接触操作)が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部151および451は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。
【0070】
図示していないが、ユーザ端末100および配信端末400は、それぞれ、ユーザ端末100および配信端末400の保持姿勢を特定するための1以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。
【0071】
ユーザ端末100および配信端末400がセンサを備えている場合、プロセッサ10および40は、それぞれ、センサの出力からユーザ端末100および配信端末400の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ10および40は、それぞれ、ユーザ端末100および配信端末400が縦向きに保持されているときには、縦長の画像を表示部152および452に表示させる縦画面表示としてもよい。一方、ユーザ端末100および配信端末400が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ10および40は、それぞれ、ユーザ端末100および配信端末400の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。
【0072】
<システム1の機能的構成>
図6は、システム1に含まれるユーザ端末100、サーバ200、およびHMDセット1000の機能的構成を示すブロック図である。
図7は、
図6に示す配信端末400の機能的構成を示すブロック図である。
【0073】
ユーザ端末100は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末100は、プロセッサ10、メモリ11、ストレージ12、通信IF13、入出力IF14、およびタッチスクリーン15等の協働によって、制御部110および記憶部120として機能する。
【0074】
サーバ200は、ユーザ端末100、HMDセット1000、および配信端末400の間の各種情報の送受信を仲介する機能を有する。サーバ200は、プロセッサ20、メモリ21、ストレージ22、通信IF23、および入出力IF24等の協働によって、制御部210および記憶部220として機能する。
【0075】
HMDセット1000(ゲームプレイ端末300)は、プレイヤの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能と、ゲーム進行情報を、サーバ200を介してユーザ端末100へリアルタイムに送信する機能を有する。HMDセット1000は、ゲームプレイ端末300のプロセッサ30、メモリ31、ストレージ32、通信IF33、入出力IF34、並びに、HMD500、HMDセンサ510、モーションセンサ520、およびコントローラ540等の協働によって、制御部310および記憶部320として機能する。
【0076】
配信端末400は、動作指図データを生成して、該動作指図データを、サーバ200を介してユーザ端末100へ送信する機能を有する。配信端末400は、プロセッサ40、メモリ41、ストレージ42、通信IF43、入出力IF44、およびタッチスクリーン45等の協働によって、制御部410および記憶部420として機能する。
【0077】
(各装置の記憶部が格納するデータ)
記憶部120は、ゲームプログラム131(プログラム)、ゲーム情報132、および、ユーザ情報133を格納する。記憶部220は、ゲームプログラム231、ゲーム情報232、ユーザ情報233、および、ユーザリスト234を格納する。記憶部320は、ゲームプログラム331、ゲーム情報332、および、ユーザ情報333を格納する。記憶部420は、ユーザリスト421、モーションリスト422、配信プログラム423(プログラム、第2プログラム)を格納する。
【0078】
ゲームプログラム131、231、331は、それぞれ、ユーザ端末100、サーバ200、HMDセット1000が実行するゲームプログラムである。ゲームプログラム131、231、331に基づいて各装置が協働して動作することにより、本ゲームが実現される。なお、ゲームプログラム131および331は、記憶部220に格納され、ユーザ端末100およびHMDセット1000にそれぞれダウンロードされる構成でもよい。なお、本実施形態では、ユーザ端末100は、ゲームプログラム131に基づいて、配信端末400から受信したデータをレンダリングし、動画を再生するものとする。換言すれば、ゲームプログラム131は、配信端末400から配信された動画指図データを用いて、動画を再生するためのプログラムでもある。該動画を再生するためのプログラムは、ゲームプログラム131と異なってもよい。この場合、記憶部120は、ゲームプログラム131とは別に、該動画を再生するためのプログラムを格納する。
【0079】
ゲーム情報132、232、332は、それぞれ、ユーザ端末100、サーバ200、HMDセット1000がゲームプログラムを実行する際に参照するデータである。ユーザ情報133、233、333は、ユーザ端末100のユーザのアカウントに関するデータである。ゲーム情報232は、各ユーザ端末100のゲーム情報132、および、HMDセット1000のゲーム情報332である。ユーザ情報233は、各ユーザ端末100のユーザ情報133、および、ユーザ情報333に含まれる、プレイヤのユーザ情報である。ユーザ情報333は、各ユーザ端末100のユーザ情報133、および、プレイヤのユーザ情報である。
【0080】
ユーザリスト234およびユーザリスト421は、ゲームに参加したユーザのリストである。ユーザリスト234およびユーザリスト421は、プレイヤによる直近のゲームプレイにおいて参加したユーザのリストの他、該ゲームプレイ以前の各ゲームプレイにおいて参加したユーザのリストを含んでいてもよい。モーションリスト422は、予め作成されている複数のモーションデータのリストである。モーションリスト422は、例えば、各モーションを識別する情報(例えば、モーション名)のそれぞれに、モーションデータが対応付けられたリストである。配信プログラム423は、ユーザ端末100にて動画を再生するための動作指図データの、ユーザ端末100への配信を実現するためのプログラムである。
【0081】
(サーバ200の機能的構成)
制御部210は、記憶部220に格納されたゲームプログラム231を実行することにより、サーバ200を統括的に制御する。例えば制御部210は、ユーザ端末100、HMDセット1000、および配信端末400の間の各種情報の送受信を仲介する。
【0082】
制御部210は、ゲームプログラム231の記述に応じて、通信仲介部211、ログ生成部212、リスト生成部213として機能する。制御部210は、ゲームプレイおよび動作指図データの配信に係る各種情報の送受信の仲介、並びに、ゲームの進行の支援のために、図示しないその他の機能ブロックとしても機能することができる。
【0083】
通信仲介部211は、ユーザ端末100、HMDセット1000、および配信端末400の間の各種情報の送受信を仲介する。例えば、通信仲介部211は、HMDセット1000から受信したゲーム進行情報をユーザ端末100へ送信する。ゲーム進行情報は、プレイヤによって操作されるキャラクタの動き、該キャラクタのパラメータ、該キャラクタが所持しているアイテムや武器、敵キャラクタなどの情報などを示すデータが含まれる。サーバ200は、ゲーム進行情報を、ゲームに参加している全てのユーザのユーザ端末100へ送信する。換言すれば、サーバ200は、共通のゲーム進行情報をゲームに参加している全てのユーザのユーザ端末100へ送信する。これにより、ゲームに参加している全てのユーザのユーザ端末100それぞれにおいて、HMDセット1000と同様にゲームが進行する。
【0084】
また、例えば、通信仲介部211は、ユーザ端末100のいずれかから受信した、プレイヤによるゲームの進行を支援するための情報を、その他のユーザ端末100、および、HMDセット1000へ送信する。該情報は、一例として、プレイヤがゲームを有利に進行するためのアイテムであって、プレイヤ(キャラクタ)に提供されるアイテムを示すアイテム情報であってもよい。アイテム情報は、アイテムを提供したユーザを示す情報(ユーザ名、ユーザIDなど)を含む。また、通信仲介部211は、配信端末400からユーザ端末100への動作指図データの配信を仲介してもよい。
【0085】
ログ生成部212は、HMDセット1000から受信するゲーム進行情報に基づいて、ゲーム進行のログを生成する。リスト生成部213は、ゲームプレイの終了後にユーザリスト234を生成する。詳細については後述するが、ユーザリスト234における各ユーザには、そのユーザが行ったプレイヤへの支援の内容を示すタグが関連付けられている。リスト生成部213は、ログ生成部212が生成したゲーム進行のログに基づいて、タグを生成し、該当するユーザに関連付ける。なお、リスト生成部213は、ゲームの運営者などがパーソナルコンピュータなどの端末装置を用いて入力した、各ユーザが行ったプレイヤへの支援の内容を、タグとして、該当するユーザに関連付けてもよい。これにより、各ユーザが行った支援の内容がより詳細なものとなる。なお、ユーザ端末100は、ユーザがゲームに参加する際、ユーザの操作に基づいて、ユーザを示す情報をサーバ200へ送信する。例えば、ユーザ端末100は、ユーザが入力したユーザIDをサーバ200へ送信する。つまり、サーバ200は、ゲームに参加している全てのユーザについて、各ユーザを示す情報を保持している。リスト生成部213は、該情報を用いて、ユーザリスト234を生成すればよい。
【0086】
(HMDセット1000の機能的構成)
制御部310は、記憶部320に格納されたゲームプログラム331を実行することにより、HMDセット1000を統括的に制御する。例えば、制御部310は、ゲームプログラム331、および、プレイヤの操作に従って、ゲームを進行させる。また、制御部310は、ゲームを進行させている間、必要に応じて、サーバ200と通信して、情報の送受信を行う。制御部310は、情報の送受信を、サーバ200を介さずにユーザ端末100と直接行ってもよい。
【0087】
制御部310は、ゲームプログラム331の記述に応じて、操作受付部311、表示制御部312、UI制御部313、アニメーション生成部314、ゲーム進行部315、仮想空間制御部316、および反応処理部317として機能する。制御部310は、実行されるゲームの性質に応じて、該ゲームに登場するキャラクタの制御などのために、図示しないその他の機能ブロックとしても機能することができる。
【0088】
操作受付部311は、プレイヤの入力操作を検知し、受け付ける。操作受付部311は、HMD500、モーションセンサ520、コントローラ540などから入力された信号を受け付け、いかなる入力操作がなされたかを判別し、その結果を制御部310の各要素に出力する。
【0089】
UI制御部313は、モニタ51、ディスプレイ530などに表示させるユーザインターフェース(以下、UI)画像を制御する。UI画像は、プレイヤが、ゲームの進行上必要な入力をHMDセット1000に対して行うためのツール、または、ゲームの進行中に出力される情報をHMDセット1000から得るためのツールである。UI画像は、これには限定されないが、例えば、アイコン、ボタン、リスト、メニュー画面などである。
【0090】
アニメーション生成部314は、各種オブジェクトの制御態様に基づいて、各種オブジェクトのモーションを示すアニメーションを生成する。例えば、アニメーション生成部314は、オブジェクト(例えば、プレイヤのアバターオブジェクト)がまるでそこにいるかのように動いたり、口を動かしたり、表情を変えたりする様子を表現したアニメーション等を生成してもよい。
【0091】
ゲーム進行部315は、ゲームプログラム331、プレイヤによる入力操作、および、該入力操作に応じたアバターオブジェクトの動作などに基づいて、ゲームを進行する。例えば、ゲーム進行部315は、アバターオブジェクトが所定の動作を行った場合に、所定のゲーム処理を行う。また、例えば、ゲーム進行部315は、ユーザ端末100におけるユーザの操作を表す情報を受信し、当該ユーザの操作に基づいてゲーム処理を行ってもよい。また、ゲーム進行部315は、ゲームの進行に従ってゲーム進行情報を生成し、サーバ200へ送信する。該ゲーム進行情報は、サーバ200を介してユーザ端末100へ送信される。これにより、HMDセット1000におけるゲームの進行が、ユーザ端末100において共有される。換言すれば、HMDセット1000におけるゲームの進行と、ユーザ端末100におけるゲームの進行とが同期する。
【0092】
仮想空間制御部316は、ゲームの進行に応じて、プレイヤに提供される仮想空間に関する各種の制御を行う。一例として、仮想空間制御部316は、各種オブジェクトを生成し、仮想空間に配置する。また、仮想空間制御部316は、仮想カメラを仮想空間に配置する。また、仮想空間制御部316は、ゲームの進行に応じて、仮想空間に配置した各種オブジェクトを動作させる。また、仮想空間制御部316は、ゲームの進行に応じて、仮想空間に配置した仮想カメラの位置、傾きを制御する。
【0093】
表示制御部312は、モニタ51、ディスプレイ530に対して、上述の各要素によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部312は、仮想空間に配置された仮想カメラからの視界に基づく画像を、ゲーム画面として、モニタ51、ディスプレイ530に表示してもよい。また、表示制御部312は、アニメーション生成部314によって生成されたアニメーションを該ゲーム画面に含めてもよい。また、表示制御部312は、UI制御部313によって制御される上述のUI画像を、該ゲーム画面に重畳して描画してもよい。
【0094】
反応処理部317は、ユーザ端末100のユーザによる、プレイヤのゲームプレイに対する反応についてフィードバックを受け付けて、これを、プレイヤに対して出力する。本実施形態では、例えば、ユーザ端末100は、ユーザの入力操作に基づいて、アバターオブジェクトに宛てたコメント(メッセージ)を作成することができる。反応処理部317は、該コメントのコメントデータを受け付けて、これを出力する。反応処理部317は、ユーザのコメントに対応するテキストデータを、モニタ51、ディスプレイ530に表示してもよいし、ユーザのコメントに対応する音声データを、図示しないスピーカから出力してもよい。前者の場合、反応処理部317は、上記テキストデータに対応する画像(すなわち、コメントの内容を含む画像)を、ゲーム画面に重畳して描画してもよい。
【0095】
(ユーザ端末100の機能的構成)
制御部110は、記憶部120に格納されたゲームプログラム131を実行することにより、ユーザ端末100を統括的に制御する。例えば、制御部110は、ゲームプログラム131、および、ユーザの操作に従って、ゲームを進行させる。また、制御部110は、ゲームを進行させている間、必要に応じて、サーバ200と通信して、情報の送受信を行う。制御部110は、情報の送受信を、サーバ200を介さずにHMDセット1000と直接行ってもよい。
【0096】
制御部110は、ゲームプログラム131の記述に応じて、操作受付部111、表示制御部112、UI制御部113、アニメーション生成部114、ゲーム進行部115、仮想空間制御部116、および動画再生部117として機能する。制御部110は、実行されるゲームの性質に応じて、ゲームの進行のために、図示しないその他の機能ブロックとしても機能することができる。
【0097】
操作受付部111は、入力部151に対するユーザの入力操作を検知し受け付ける。操作受付部111は、タッチスクリーン15およびその他の入出力IF14を介したコンソールに対してユーザが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部110の各要素に出力する。
【0098】
例えば、操作受付部111は、入力部151に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部111は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部111は、連続して検知されていた入力が途切れると、タッチスクリーン15から接触入力が解除されたことを検知する。
【0099】
UI制御部113は、ユーザの入力操作、および、受信したゲーム進行情報の少なくとも何れかに応じて、UIを構築するために表示部152に表示させるUI画像を制御する。UI画像は、ユーザが、ゲームの進行上必要な入力をユーザ端末100に対して行うためのツール、または、ゲームの進行中に出力される情報をユーザ端末100から得るためのツールである。UI画像は、これには限定されないが、例えば、アイコン、ボタン、リスト、メニュー画面などである。
【0100】
アニメーション生成部114は、各種オブジェクトの制御態様に基づいて、各種オブジェクトのモーションを示すアニメーションを生成する。
【0101】
ゲーム進行部115は、ゲームプログラム131、受信したゲーム進行情報、および、ユーザによる入力操作などに基づいて、ゲームを進行する。ゲーム進行部115は、ユーザによる入力操作により、所定のゲーム処理を行った場合、該ゲーム処理に関する情報を、サーバ200を介してHMDセット1000へ送信する。これにより、該所定のゲーム処理が、HMDセット1000において共有される。換言すれば、HMDセット1000におけるゲームの進行と、ユーザ端末100におけるゲームの進行とが同期する。所定のゲーム処理とは、例えば、アバターオブジェクトにアイテムを提供する処理であり、この例の場合、ゲーム処理に関する情報は、上述したアイテム情報である。
【0102】
仮想空間制御部116は、ゲームの進行に応じて、ユーザに提供される仮想空間に関する各種の制御を行う。一例として、仮想空間制御部116は、各種オブジェクトを生成し、仮想空間に配置する。また、仮想空間制御部116は、仮想カメラを仮想空間に配置する。また、仮想空間制御部116は、ゲームの進行、具体的には、受信したゲーム進行情報に応じて、仮想空間に配置した各種オブジェクトを動作させる。また、仮想空間制御部316は、ゲームの進行、具体的には、受信したゲーム進行情報に応じて、仮想空間に配置した仮想カメラの位置、傾きを制御する。
【0103】
表示制御部112は、表示部152に対して、上述の各要素によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部112は、ユーザに提供される仮想空間に配置された仮想カメラからの視界に基づく画像を、ゲーム画面として、表示部152に表示してもよい。また、表示制御部112は、アニメーション生成部114によって生成されたアニメーションを該ゲーム画面に含めてもよい。また、表示制御部112は、UI制御部113によって制御される上述のUI画像を、該ゲーム画面に重畳して描画してもよい。いずれにしても、表示部152に表示されるゲーム画面は、他のユーザ端末100、および、HMDセット1000にて表示されるゲーム画面と同様のゲーム画面である。
【0104】
動画再生部117は、配信端末400から受信した動作指図データを解析(レンダリング)し、動画を再生する。
【0105】
(配信端末400の機能的構成)
制御部410は、記憶部420に格納されたプログラム(不図示)を実行することにより、配信端末400を統括的に制御する。例えば、制御部410は、該プログラム、および、配信端末400のユーザ(本実施形態ではプレイヤ)の操作に従って、動作指図データを生成し、ユーザ端末100に配信する。また、制御部410は、必要に応じて、サーバ200と通信して、情報の送受信を行う。制御部410は、情報の送受信を、サーバ200を介さずにユーザ端末100と直接行ってもよい。
【0106】
制御部410は、プログラムの記述に応じて、通信制御部411、表示制御部412、操作受付部413、音声受付部414、モーション特定部415、および動作指図データ生成部416として機能する。制御部410は、動作指図データの生成および配信のために、図示しないその他の機能ブロックとしても機能することができる。
【0107】
通信制御部411は、サーバ200、または、サーバ200を介したユーザ端末100との情報の送受信を制御する。通信制御部411は、一例として、サーバ200からユーザリスト421を受信する。また、通信制御部411は、一例として、動作指図データをユーザ端末100へ送信する。
【0108】
表示制御部412は、表示部452に対して、各要素によって実行された処理結果が反映された各種画面を出力する。表示制御部412は、一例として、受信したユーザリスト234を含む画面を表示する。また、表示制御部412は、一例として、配信する動作指図データに含まれる、アバターオブジェクトを動作させるためのモーションデータを、プレイヤに選択させるためのモーションリスト422を含む画面を表示する。
【0109】
操作受付部413は、入力部151に対するプレイヤの入力操作を検知し受け付ける。操作受付部111は、タッチスクリーン45およびその他の入出力IF44を介したコンソールに対してプレイヤが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部410の各要素に出力する。
【0110】
例えば、操作受付部413は、入力部451に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部413は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部413は、連続して検知されていた入力が途切れると、タッチスクリーン45から接触入力が解除されたことを検知する。
【0111】
音声受付部414は、配信端末400の周囲で発生した音声を受け付け、該音声の音声データを生成する。音声受付部414は、一例として、プレイヤが発話した音声を受け付け、該音声の音声データを生成する。
【0112】
モーション特定部415は、プレイヤの入力操作に応じて、モーションリスト422から、プレイヤが選択したモーションデータを特定する。
【0113】
動作指図データ生成部416は、動作指図データを生成する。一例として、動作指図データ生成部416は、生成された音声データと、特定されたモーションデータとを含む動作指図データを生成する。
【0114】
なお、
図6に示すHMDセット1000、サーバ200、およびユーザ端末100の機能、並びに、
図7に示す配信端末400の機能は一例にすぎない。HMDセット1000、サーバ200、ユーザ端末100、および配信端末400の各装置は、他の装置が備える機能の少なくとも一部を備えていてもよい。さらに、HMDセット1000、サーバ200、ユーザ端末100、および配信端末400以外のさらに別の装置をシステム1の構成要素とし、該別の装置にシステム1における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、HMDセット1000、サーバ200、ユーザ端末100、および配信端末400、並びに、それ以外の別の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。
【0115】
<仮想空間の制御処理>
図8は、プレイヤに提供される仮想空間、および、ユーザ端末100のユーザに提供される仮想空間の制御処理の流れの一例を示すフローチャートである。
図9は、ある実施の形態に従う、プレイヤに提供される仮想空間600A、および、プレイヤが視認する視界画像を示す図である。
図10は、ある実施の形態に従う、ユーザ端末100のユーザに提供される仮想空間600B、および、ユーザが視認する視界画像を示す図である。なお以降、仮想空間600Aおよび600Bを区別する必要が無い場合、「仮想空間600」と記載する。
【0116】
ステップS1において、プロセッサ30は、仮想空間制御部316として、
図9に示す仮想空間600Aを規定する。プロセッサ30は、仮想空間データ(不図示)を用いて、仮想空間600Aを規定する。仮想空間データは、ゲームプレイ端末300に記憶されていてもよいし、プロセッサ30が、ゲームプログラム331に基づいて生成してもよいし、プロセッサ30が、サーバ200などの外部の装置から取得してもよい。
【0117】
仮想空間600は、一例として、中心として定義された点の360度方向の全体を覆う全天球状の構造を有する。
図9および
図10では、説明を複雑にしないために、仮想空間600のうちの上半分の天球が例示されている。
【0118】
ステップS2において、プロセッサ30は、仮想空間制御部316として、仮想空間600Aに、アバターオブジェクト610(キャラクタ)を配置する。アバターオブジェクト610は、プレイヤに関連付けられたアバターオブジェクトであり、プレイヤの入力操作に従って動作する。
【0119】
ステップS3において、プロセッサ30は、仮想空間制御部316として、仮想空間600Aに、その他のオブジェクトを配置する。
図9の例では、プロセッサ30は、オブジェクト631~634を配置する。その他のオブジェクトは、例えば、ゲームプログラム331に従って動作するキャラクタオブジェクト(いわゆるノンプレイヤキャラクタ、NPC)、仮想手などの操作オブジェクト、ゲームの進行に従って配置される動物、植物、人工物、自然物などを模したオブジェクトなどを含み得る。
【0120】
ステップS4において、プロセッサ30は、仮想空間制御部316として、仮想空間600Aに仮想カメラ620Aを配置する。プロセッサ30は、一例として、仮想カメラ620Aを、アバターオブジェクト610の頭部の位置に配置する。
【0121】
ステップS5において、プロセッサ30は、視界画像650をモニタ51およびディスプレイ530に表示する。プロセッサ30は、仮想カメラ620Aの初期の位置と傾きとに応じて、仮想空間600Aにおける仮想カメラ620Aからの視界である視界領域640Aを定義する。そして、プロセッサ30は、視界領域640Aに対応する視界画像650を定義する。プロセッサ30は、視界画像650をモニタ51およびディスプレイ530に出力することによって、視界画像650をHMD500およびディスプレイ530に表示させる。
【0122】
図9の例において、
図9(A)に示すように、オブジェクト634の一部が視界領域640Aに含まれているため、視界画像650は、
図9(B)に示すようにオブジェクト634の一部を含む。
【0123】
ステップS6において、プロセッサ30は、初期配置情報を、サーバ200を介してユーザ端末100へ送信する。初期配置情報とは、仮想空間600Aにおける各種オブジェクトの初期の配置位置を示す情報である。
図9の例において、初期配置情報は、アバターオブジェクト610、および、オブジェクト631~634の初期の配置位置の情報を含む。初期配置情報は、ゲーム進行情報の1つであると表現することもできる。
【0124】
ステップS7において、プロセッサ30は、仮想空間制御部316として、HMD500の動きに応じて仮想カメラ620Aを制御する。具体的には、プロセッサ30は、HMD500の動き、すなわち、プレイヤの頭部の姿勢に応じて、仮想カメラ620Aの向きおよび傾きを制御する。後述のように、プロセッサ30は、プレイヤが頭部を動かす(頭部の姿勢を変更する)と、この動きに合わせて、アバターオブジェクト610の頭部を動かす。プロセッサ30は、例えば、アバターオブジェクト610の視線の方向と、仮想カメラ620Aの視線の方向とが一致するように、仮想カメラ620Aの向きおよび傾きを制御する。ステップS8において、プロセッサ30は、仮想カメラ620Aの向きおよび傾きが変更されたことに応じて、視界画像650を更新する。
【0125】
ステップS9において、プロセッサ30は、仮想空間制御部316として、プレイヤの動きに応じて、アバターオブジェクト610を動かす。一例として、プロセッサ30は、プレイヤが現実空間で移動したことに応じて、仮想空間600Aでアバターオブジェクト610を移動させる。また、プロセッサ30は、プレイヤが現実空間で頭部を動かしたことに応じて、仮想空間600Aでアバターオブジェクト610の頭部を動かす。
【0126】
ステップS10において、プロセッサ30は、仮想空間制御部316として、仮想カメラ620Aを、アバターオブジェクト610に追随するように移動させる。つまり、仮想カメラ620Aは、アバターオブジェクト610が移動しても、常にアバターオブジェクト610の頭部の位置にある。
【0127】
プロセッサ30は、仮想カメラ620Aの移動に応じて、視界画像650を更新する。つまり、プロセッサ30は、プレイヤの頭部の姿勢と、仮想空間600Aにおける仮想カメラ620Aの位置とに応じて、視界領域640Aを更新する。その結果、視界画像650が更新される。
【0128】
ステップS11において、プロセッサ30は、アバターオブジェクト610の動作指図データを、サーバ200を介してユーザ端末100へ送信する。ここでの動作指図データは、仮想体験中(例えば、ゲームプレイ中)において、プレイヤの動作を取り込んだモーションデータ、プレイヤが発話した音声の音声データ、コントローラ540に対する入力操作の内容を示す操作データの少なくとも何れかを含む。プレイヤがゲームをプレイしている場合、動作指図データは、例えば、ゲーム進行情報としてユーザ端末100へ送信される。
【0129】
ステップS7~S11の処理は、プレイヤがゲームをプレイしている間、継続して繰り返し実行される。
【0130】
ステップS21において、ユーザ3のユーザ端末100のプロセッサ10は、仮想空間制御部116として、
図10に示す仮想空間600Bを規定する。プロセッサ10は、仮想空間データ(不図示)を用いて、仮想空間600Bを規定する。仮想空間データは、ユーザ端末100に記憶されていてもよいし、プロセッサ10が、ゲームプログラム131に基づいて生成してもよいし、プロセッサ10が、サーバ200などの外部の装置から取得してもよい。
【0131】
ステップS22において、プロセッサ10は、初期配置情報を受信する。ステップS23において、プロセッサ10は、仮想空間制御部116として、初期配置情報に応じて各種オブジェクトを仮想空間600Bに配置する。
図10の例の場合、各種オブジェクトは、アバターオブジェクト610、および、オブジェクト631~634である。
【0132】
ステップS24において、プロセッサ10は、仮想空間制御部116として、仮想空間600Bに仮想カメラ620Bを配置する。プロセッサ10は、一例として、仮想カメラ620Bを、
図10(A)に示す位置に配置する。
【0133】
ステップS25において、プロセッサ10は、視界画像660を表示部152に表示する。プロセッサ10は、仮想カメラ620Bの初期の位置と傾きとに応じて、仮想空間600Bにおける仮想カメラ620Bからの視界である視界領域640Bを定義する。そして、プロセッサ10は、視界領域640Bに対応する視界画像660を定義する。プロセッサ10は、視界画像660を表示部152に出力することによって、視界画像660を表示部152に表示させる。
【0134】
図10の例において、
図10(A)に示すように、アバターオブジェクト610およびオブジェクト631が視界領域640Bに含まれているため、視界画像660は、
図10(B)に示すようにアバターオブジェクト610およびオブジェクト631を含む。
【0135】
ステップS26において、プロセッサ10は、動作指図データを受信する。ステップS27において、プロセッサ10は、仮想空間制御部116として、動作指図データに応じて、仮想空間600Bでアバターオブジェクト610を動かす。換言すれば、プロセッサ10は、リアルタイムレンダリングにより、アバターオブジェクト610が動作している映像を再生する。
【0136】
ステップS28において、プロセッサ10は、仮想空間制御部116として、操作受付部111として受け付けたユーザの操作に応じて仮想カメラ620Bを制御する。ステップS29において、プロセッサ10は、仮想カメラ620Bの仮想空間600Bにおける位置、仮想カメラ620Bの向きおよび傾きが変更されたことに応じて、視界画像660を更新する。なお、ステップS28において、プロセッサ10は、アバターオブジェクト610の動き、例えば、アバターオブジェクト610の移動や、向きの変更に応じて仮想カメラ620Bを自動的に制御してもよい。例えば、プロセッサ10は、常にアバターオブジェクト610を正面から撮影するように自動的に仮想カメラ620Bを移動させたり、向きおよび傾きを変更したりしてもよい。また、一例として、プロセッサ10は、アバターオブジェクト610の動きに応じて、常にアバターオブジェクト610を後方から撮影するように自動的に仮想カメラ620Bを移動させたり、向きおよび傾きを変更したりしてもよい。
【0137】
このように、仮想空間600Aにおいて、アバターオブジェクト610は、プレイヤの動きに応じて動作する。この動作を示す動作指図データは、ユーザ端末100に送信される。仮想空間600Bにおいて、アバターオブジェクト610は、受信した動作指図データに応じて動作する。これにより、仮想空間600Aと仮想空間600Bとにおいて、アバターオブジェクト610は同様の動作を行う。換言すれば、ユーザ3は、ユーザ端末100を用いて、プレイヤの動作に応じたアバターオブジェクト610の動作を視認することができる。
【0138】
<ゲーム概要>
図11は、ユーザ端末100において表示される視界画像の他の例を示す図である。具体的には、プレイヤがプレイしている、システム1が実行するゲーム(本ゲーム)のゲーム画面の一例を示す図である。
【0139】
本ゲームは、一例として、銃、ナイフなどの武器を操作するアバターオブジェクト610と、NPCである複数の敵オブジェクト671とを仮想空間600に登場させ、アバターオブジェクト610に敵オブジェクト671との対戦を行わせるゲームである。アバターオブジェクト610の体力、使用可能なマガジンの数、銃の残弾数、敵オブジェクト671の残数等の各種ゲームパラメータは、ゲームの進行に応じて更新される。
【0140】
本ゲームには、複数のステージが用意されており、プレイヤは、各ステージに関連付けられている所定の達成条件を成立させることにより、当該ステージをクリアすることができる。所定の達成条件としては、例えば、出現する敵オブジェクト671をすべて倒すことや、出現する敵オブジェクト671のうちボスオブジェクトを倒すこと、所定のアイテムを獲得すること、所定位置に到達することなどにより成立する条件を含むものであってもよい。該達成条件は、ゲームプログラム131内で定義されている。なお、本ゲームでは、ゲームの内容に即し、達成条件が成立された場合にプレイヤはステージをクリア、換言すれば、アバターオブジェクト610の敵オブジェクト671への勝利(アバターオブジェクト610と敵オブジェクト671との間の勝敗)が決定される。これに対し、例えば、システム1で実行されるゲームがレースゲーム等である場合、ゴールに到達するという条件が成立した場合に、アバターオブジェクト610の順位が決定される。
【0141】
本ゲームでは、HMDセット1000及び複数のユーザ端末100の間で仮想空間を共有するために、ゲーム進行情報が、所定時間毎に複数のユーザ端末100にライブ配信される。この結果、ゲームを視聴中のユーザ端末100のタッチスクリーン15には、ユーザ端末100に対応する仮想カメラ620Bによって規定される視界領域の視界画像が表示される。また、視界画像の右上段および左上段には、アバターオブジェクト610の体力、使用可能なマガジンの数、銃の残弾数、敵オブジェクト671の残数等を表すパラメータ画像が重畳的に表示される。この視界画像は、ゲーム画面と表現することもできる。
【0142】
ゲーム進行情報は、上述したとおり、プレイヤの動作を取り込んだモーションデータ、プレイヤが発話した音声の音声データ、コントローラ540に対する入力操作の内容を示す操作データを含む。これらのデータはすなわち、アバターオブジェクト610の位置、姿勢、向きなどを特定するための情報、敵オブジェクト671の位置、姿勢、向きなどを特定する情報、その他オブジェクト(例えば、障害物オブジェクト672、673)の位置などを特定する情報である。プロセッサ10は、ゲーム進行情報を解析(レンダリング)することにより、各オブジェクトの位置、姿勢、向きなどを特定する。
【0143】
ゲーム情報132は、アバターオブジェクト610、敵オブジェクト671、障害物オブジェクト672、673等の各種オブジェクトのデータを含む。プロセッサ10は、該データと、ゲーム進行情報の解析結果とを用いて、各オブジェクトの位置、姿勢、向きなどを更新する。これにより、ゲームが進行し、仮想空間600Bにおける各オブジェクトは、仮想空間600Aにおける各オブジェクトと同様に動く。具体的には、仮想空間600Bにおいて、アバターオブジェクト610を含む各オブジェクトは、ユーザ端末100に対するユーザからの操作の有無に関わらず、ゲーム進行情報に基づいて動作する。
【0144】
ユーザ端末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をタップする操作であってもよい。
【0145】
UI画像701がタップされると、UI画像711が、視界画像に重畳して表示される。UI画像711は、例えば、マガジンのアイコンが描かれたUI画像711A、救急箱のアイコンが描かれたUI画像711B、三角コーンのアイコンが描かれたUI画像711C、バリケードのアイコンが描かれたUI画像711Dを含む。アイテム投入操作は、例えば、いずれかのUI画像をタップする操作に相当する。
【0146】
一例として、UI画像711Aがタップされると、アバターオブジェクト610が使用する銃の残弾数が増加する。UI画像711Bがタップされると、アバターオブジェクト610の体力が回復する。UI画像711Cおよび711Dがタップされると、敵オブジェクト671の移動を妨害する障害物オブジェクト672、673が仮想空間に配置される。障害物オブジェクト672、673は、一方が他方に比べて、敵オブジェクト671の移動をより妨害するものであってもよい。
【0147】
プロセッサ10は、アイテム投入操作が行われたことを示すアイテム投入情報を、サーバ200へ送信する。アイテム投入情報には、アイテム投入操作により指定されたアイテムの種別を特定するための情報が少なくとも含まれる。アイテム投入情報には、アイテムが配置される位置を示す情報など、アイテムに関するその他の情報が含まれていてもよい。アイテム投入情報は、サーバ200を介して、他のユーザ端末100、および、HMDセット1000へ送信される。
【0148】
図12は、ユーザ端末100において表示される視界画像の他の例を示す図である。具体的には、本ゲームのゲーム画面の一例を示す図であり、ゲームプレイ中のプレイヤとユーザ端末100とのコミュニケーションについて説明するための図である。
【0149】
図12(A)の例において、ユーザ端末100は、アバターオブジェクト610に発話691を実行させている。具体的には、ユーザ端末100は、ゲーム進行情報に含まれる音声データに従って、アバターオブジェクト610に発話691を実行させている。発話691の内容は、プレイヤ4が発話した「弾が無いよー!」というものである。すなわち、発話691の内容は、マガジンが0、銃に装填した銃弾が1となったことにより、敵オブジェクト671を攻撃する手段を失いそうであることを各ユーザに伝えるものである。
【0150】
なお、
図12(A)では、アバターオブジェクト610の発話を視覚的に示すため吹き出しを用いているが、実際は、ユーザ端末100のスピーカから音声が出力される。なお、音声出力とともに、
図12(A)に示す吹き出し(すなわち、音声の内容のテキストを含む吹き出し)が視界画像中に表示されてもよい。これは、後述する発話692でも同様である。
【0151】
UI画像702に対するタップ操作を受け付けると、ユーザ端末100は、
図12(B)に示すように、UI画像705および706(メッセージUI)を視界画像に重畳して表示する。UI画像705は、アバターオブジェクト610(換言すれば、プレイヤ)に対するコメントを表示するUI画像である。UI画像706は、入力されたコメントを送信するためコメント送信操作をユーザ3から受け付けるUI画像である。
【0152】
ユーザ端末100は、一例として、UI画像705へのタップ操作を受け付けると、キーボードを模したUI画像(不図示、以下、単に「キーボード」と記載)をタッチスクリーン15に表示させる。ユーザ端末100は、キーボードに対するユーザの入力操作に応じたテキストを、UI画像705に表示させる。
図12(B)の例では、「マガジン送るね」というテキストがUI画像705に表示されている。
【0153】
ユーザ端末100は、テキスト入力後に、一例として、UI画像706へのタップ操作を受け付けると、入力した内容(テキストの内容)を示す情報と、ユーザを示す情報とを含むコメント情報をサーバ200へ送信する。コメント情報は、サーバ200を介して、他のユーザ端末100、および、HMDセット1000へ送信される。
【0154】
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画像にユーザ名とコメントの内容とが含まれていてもよい。
【0155】
図12(C)の例では、
図12に示すユーザ端末100のユーザである、「AAAAA」というユーザ名のユーザが、上述したとおりコメントを入力し、送信したことにより、タッチスクリーン15にUI画像703Bおよび704Bが表示されている。UI画像703Bにはユーザ名「AAAAA」が含まれており、UI画像704Bには、
図12(B)の例において入力された「マガジン送るね!」とのコメントが含まれている。
【0156】
また、
図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に関する演出を実行し、アイテムオブジェクトの効果を発動させる処理を実行する。
【0157】
図12(D)の例では、アイテムオブジェクトの効果を発動させる処理の実行により、マガジンの数が0から1に増加している。この結果、プレイヤは、ユーザ「AAAAA」に対して、「ありがとう!」と発話し、該発話の音声データが、各ユーザ端末100に送信される。これにより、各ユーザ端末100は、アバターオブジェクト610の発話692として、「ありがとう!」という音声を出力する。
【0158】
以上のように、本ゲームにおいては、プレイヤの発話に基づくアバターオブジェクト610の発話音声の出力と、各ユーザによるコメントの入力とにより、ユーザとアバターオブジェクト610とのコミュニケーションが実現される。
【0159】
(ゲームプレイ端末300におけるゲーム進行処理)
図13は、ゲームプレイ端末300で実行されるゲーム進行処理の流れの一例を示すフローチャートである。
【0160】
ステップS31において、プロセッサ30は、ゲーム進行部315として、ゲームプログラム331とプレイヤの動きとに基づいてゲームを進行させる。ステップS32において、プロセッサ30は、ゲーム進行情報を生成し、ユーザ端末100へ配信する。具体的には、プロセッサ30は、生成したゲーム進行情報を、サーバ200を介して、各ユーザ端末100へ送信する。
【0161】
ステップS33において、プロセッサ30は、アイテム投入情報を受信すると(S33でYES)、ステップS34において、アイテム投入情報に基づいて、アイテムオブジェクトを仮想空間600Aに配置する。一例として、プロセッサ30は、アイテムオブジェクトの配置の前に、演出オブジェクト674を仮想空間600Aに配置する(
図11(C)参照)。演出オブジェクト674は、例えば、プレゼント箱を模したオブジェクトであってもよい。プロセッサ30は、一例として、アイテム投入情報にて示された経過時間が経過した後に、演出オブジェクト674に関する演出を実行してもよい。該演出は、例えば、プレゼント箱の蓋が開くアニメーションであってもよい。プロセッサ30は、該アニメーションの実行の後、アイテムオブジェクトの効果を発動させる処理を実行する。例えば、
図11(D)の例では、障害物オブジェクト673を配置する。
【0162】
プロセッサ30は、アニメーションの実行の後、タップ操作されたUI画像に対応するアイテムオブジェクトを仮想空間600Aに配置してもよい。例えば、UI画像711Aに対してタップ操作が行われた場合、プロセッサ30は、アニメーションの実行の後、マガジンを示すマガジンオブジェクトを仮想空間600Aに配置する。また、UI画像711Bに対してタップ操作が行われた場合、プロセッサ30は、アニメーションの実行の後、救急箱を示す救急箱オブジェクトを仮想空間600Aに配置する。プロセッサ30は、例えば、マガジンオブジェクトまたは救急箱オブジェクトの位置に、アバターオブジェクト610が移動した場合に、マガジンオブジェクトまたは救急箱オブジェクトの効果を発動させる処理を実行してもよい。
【0163】
プロセッサ30は、ゲームが終了するまで、ステップS31~S34の処理を継続し、繰り返す。ゲームが終了した場合、例えば、プレイヤがゲームを終了するための所定の入力操作を入力した場合(ステップS35でYES)、
図13に示す処理は終了する。
【0164】
(ユーザ端末100におけるゲーム進行処理)
図14は、ユーザ端末100で実行されるゲーム進行処理の流れの一例を示すフローチャートである。
【0165】
ステップS41において、プロセッサ10は、ゲーム進行情報を受信する。ステップS42において、プロセッサ10は、ゲーム進行部115として、ゲーム進行情報に基づいてゲームを進行させる。
【0166】
ステップS43において、プロセッサ10が、ユーザ3によるアイテム投入操作を受け付けると(ステップS43にてYES)、ステップS44において、プロセッサ10は、仮想通貨を消費し、演出オブジェクト674を仮想空間600Bに配置する。ここで、仮想通貨は、ゲームへの参加の前、あるいは、ゲームへの参加中に、ユーザ3がプロセッサ10に対し所定の操作を行うことにより購入(本ゲームに対して課金)されるものであってもよいし、所定の条件を満たした場合にユーザ3に付与されるものであってもよい。所定の条件とは、本ゲームにおけるクエストのクリア等、本ゲームへの参加が必要なものであってもよいし、アンケートに答える等、本ゲームへの参加が不要なものであってもよい。仮想通貨の金額(仮想通貨の所有量)は、一例として、ゲーム情報132としてユーザ端末100に記憶される。
【0167】
ステップS45において、プロセッサ10は、アイテム投入情報をサーバ200へ送信する。アイテム投入情報は、サーバ200を介してゲームプレイ端末300へ送信される。
【0168】
プロセッサ10は、演出オブジェクト674の配置後、所定時間が経過すると、アイテムオブジェクトを仮想空間600Aに配置する。
図11の例では、障害物オブジェクト673を配置する。つまり、ユーザ3が、UI画像711Cへのタップ操作を入力することにより、所定量の仮想通貨が消費され、障害物オブジェクト673が配置される。
【0169】
プロセッサ10は、ゲームが終了するまで、ステップS41~S45の処理を継続し、繰り返す。ゲームが終了した場合、例えば、プレイヤがゲームを終了するための所定の入力操作を行った場合や、ユーザ3が、ゲームから途中退席するための所定の入力操作を行った場合(ステップS46でYES)、
図14に示す処理は終了する。
【0170】
(サーバ200におけるゲーム進行処理)
図15は、サーバ200で実行されるゲーム進行処理の流れの一例を示すフローチャートである。
【0171】
ステップS51において、プロセッサ20は、ゲーム進行情報をゲームプレイ端末300から受信する。ステップS52において、プロセッサ20は、ログ生成部212として、ゲーム進行のログ(以下、プレイログ)を更新する。なお、プレイログは、一例として、ゲームプレイ端末300から初期配置情報を受信したとき、プロセッサ20が生成する。
【0172】
ステップS53において、プロセッサ20は、受信したゲーム進行情報を、各ユーザ端末100へ送信する。
【0173】
ステップS54において、アイテム投入情報をいずれかのユーザ端末100から受信した場合(ステップS54にてYES)、ステップS55において、プロセッサ20は、ログ生成部212としてプレイログを更新する。ステップS56において、プロセッサ20は、受信したアイテム投入情報をゲームプレイ端末300へ送信する。
【0174】
プロセッサ20は、ゲームが終了するまで、ステップS51~S56の処理を継続し、繰り返す。ゲームが終了した場合、例えば、ゲームプレイ端末300から、ゲームが終了したことを示す情報を受信した場合(ステップS57でYES)、ステップS58において、プロセッサ20は、リスト生成部213として、プレイログからゲームに参加したユーザのリスト(ユーザリスト234)を生成する。プロセッサ20は、生成したユーザリスト234を、サーバ200に記憶する。
【0175】
図16は、ユーザリスト234の一具体例を示す図である。「ユーザ」のカラムには、ゲームに参加した各ユーザを示す情報(例えば、ユーザ名)が格納されている。「タグ」のカラムには、各ユーザがプレイヤに対して行った支援に基づいて生成された情報(タグ)が格納されている。
図16の例において、「タグ」のカラムに格納されたタグのうち、鍵括弧を有さないものは、プロセッサ20が自動生成した情報であり、鍵括弧を有するものは、ゲームの運営者が手動で入力した情報である。
【0176】
図16の例において、ユーザ「AAAAA」には、マガジン、10F、ボス、「マガジンのプレゼントによりボスに勝利」という情報が対応付けられている。これは、例えば、10Fというステージでのボス戦において、ユーザ「AAAAA」がマガジンを投入し、その投入されたマガジンの銃弾でアバターオブジェクト610がボスに勝利したことを示している。
【0177】
また、ユーザ「BBBBB」には、救急箱、3F、ザコ、「ゲームオーバー寸前で回復」という情報が対応付けられている、これは、例えば、3Fというステージのザコ敵との戦闘において、ユーザ「BBBBB」が救急箱を投入し、その結果、アバターオブジェクト610の体力が0になる(ゲームオーバーになる)寸前で体力が回復したことを示している。
【0178】
また、ユーザ「CCCCC」には、バリケード、5F、ザコ、「バリケードでゾンビを二人足止め」という情報が対応付けられている。これは、例えば、5Fというステージのザコ敵との戦闘において、ユーザ「CCCCC」がバリケード(
図11における障害物オブジェクト672)を投入し、その結果、二人のザコ敵の足止めに成功したことを示している。
【0179】
図16の例では、各ユーザ3のユーザ名に対し、行った支援が1つ対応付けられているが、支援を複数回行なったユーザ3のユーザ名には、複数回の支援それぞれのタグが対応付けられる。ユーザリスト234において、該それぞれのタグは区別されていることが好ましい。これにより、ゲーム終了後に、配信端末400を用いてユーザリスト421を参照するプレイヤが、各支援の内容を正確に把握できる。
【0180】
<動作指図データの配信>
(配信端末400における配信処理)
図17は、配信端末400で実行される配信処理の流れの一例を示すフローチャートである。
図18は、配信端末400に表示される画面の一具体例を示す図である。
図19は、配信端末に表示される画面の他の具体例を示す図である。
【0181】
ステップS61において、プロセッサ40は、操作受付部413として、ゲームに参加したユーザのリスト(ユーザリスト234)を表示するための第1操作を受け付ける。
図18(A)に示すダウンロード画面721は、ユーザリスト234をサーバ200からダウンロードし、表示部452に表示させるための画面である。ダウンロード画面721は、一例として、
図17に示す配信処理を実行するアプリケーションの起動操作を、配信端末400に入力した直後に表示される画面である。
【0182】
ダウンロード画面721は、一例として、UI画像722および723を含む。UI画像722は、ユーザリスト234をダウンロードするための操作、すなわち、上記第1操作を受け付ける。第1操作は、例えば、UI画像722をタップする操作であってもよい。UI画像723は、アプリケーションを終了するための操作を受け付ける。該操作は、例えば、UI画像723をタップする操作であってもよい。
【0183】
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に表示させることができる。
【0184】
一例として、レコード画像732A~732Cは、それぞれ、ユーザ名733A~733C、タグ情報734A~734C、および、アイコン735A~735Cを含む。以降、レコード画像732A~732C、ユーザ名733A~733C、タグ情報734A~734C、および、アイコン735A~735Cについて、区別する必要が無い場合、それぞれ、「レコード画像732」、「ユーザ名733」、「タグ情報734」、「アイコン735」と記載する。
【0185】
ユーザ名733は、ユーザリスト234において、「ユーザ」のカラムに格納されている、ゲームに参加した各ユーザを示す情報である。タグ情報734は、ユーザリスト234において、ゲームに参加した各ユーザを示す情報のそれぞれに対応付けられているタグを示す情報である。例えば、レコード画像732Aは、ユーザ名733Aとして、「AAAAA」を含む。このため、レコード画像732Aは、タグ情報734Aとして、ユーザリスト234において「AAAAA」に対応付けられている、『マガジン、10F、ボス、「マガジンのプレゼントによりボスに勝利」』を含む。アイコン735は、例えば、ユーザが事前に設定した画像である。
【0186】
なお、プロセッサ40は、受信したユーザリストを配信端末400に記憶してもよい(
図7のユーザリスト421)。ダウンロード画面721は、ユーザリスト421を表示部452に表示するためのUI画像(不図示)を含んでいてもよい。この例において、該UI画像がタップされた場合、プロセッサ40は、ユーザリスト234のダウンロードを行わず、ユーザリスト421を読み出し、該ユーザリスト421からユーザリスト画面を生成し、表示部452に表示させる。
【0187】
ステップS64において、プロセッサ40は、操作受付部413として、ユーザリスト画面731に含まれるユーザの何れかを選択するための第2操作を受け付ける。第2操作は、一例として、ユーザリスト画面731におけるレコード画像732の何れかをタップする操作であってもよい。
図18(B)の例では、プレイヤは、レコード画像732Aへのタップ操作を入力している。すなわち、プレイヤは、動作指図データを配信するユーザとしてユーザ「AAAAA」を選択している。
【0188】
レコード画像732に対するタップ操作を受け付けると、ステップS65において、プロセッサ40は、表示制御部412として、モーションリスト422を表示部452に表示させる。具体的には、プロセッサ40は、モーションリスト422に基づいて生成されたモーションリスト画面を、表示部452に表示させる。モーションリスト画面は、一例として、
図19に示すモーションリスト画面741であってもよい。モーションリスト画面741は、モーションリスト422における各レコードに対応するレコード画像からなる。
図19の例では、レコード画像として、レコード画像742A~742Cを記載しているが、レコード画像の数は3つに限定されない。
図19の例において、モーションリスト422におけるレコードの数が4より多い場合、プレイヤは、例えば画面をスクロールする操作(例えば、ドラッグ操作やフリック操作)をタッチスクリーン45に入力することにより、他のレコード画像を表示部452に表示させることができる。
【0189】
一例として、レコード画像742A~742Cは、それぞれ、モーション名743A~743C、モーション画像744A~744C、および、UI画像745A~745Cを含む。以降、レコード画像742A~742C、モーション名743A~743C、モーション画像744A~744C、および、UI画像745A~745Cについて、区別する必要が無い場合、それぞれ、「レコード画像7432」、「モーション名743」、「モーション画像744」、「UI画像745」と記載する。
【0190】
モーション名743は、モーションリスト422に格納されているモーションを識別する情報である。モーション画像744は、モーションリスト422において、各モーション名に対応付けられているモーションデータから生成される画像である。プロセッサ40は、一例として、各モーションデータにおける最初の姿勢をとるアバターオブジェクト610の画像を、モーション画像744とてレコード画像742に含める。モーション画像744は、プレイヤによる所定の操作(例えば、モーション画像744に対するタップ操作)を受け付けるUI画像であってもよい。プロセッサ40は、該所定の操作を受け付けた場合、モーションデータに基づいてアバターオブジェクト610が動作するモーション動画を再生してもよい。プロセッサ40は、モーション動画が終了すると、自動的にモーションリスト画面741を再表示してもよい。
【0191】
なお、レコード画像742は、モーション画像744に代えて、例えば、「モーション再生」とのテキストを含むUI画像を含んでもよい。
【0192】
ステップS66において、プロセッサ40は、操作受付部413として、モーションを選択する第3操作を受け付ける。第3操作は、一例として、UI画像745へのタップ操作であってもよい。つまり、UI画像745は、各レコード画像742に対応するモーションデータを選択する操作を受け付ける。第3操作を受け付けたことにより、プロセッサ40は、モーション特定部415として、プレイヤが選択したモーションデータを特定する。
【0193】
ステップS67において、プロセッサ40は、表示制御部412および音声受付部414として、アバターオブジェクト610が、選択されたモーションデータに基づき動作するモーション動画を再生しながら、プレイヤの音声入力を受け付ける。
【0194】
図20は、プレイヤ4による音声入力の一具体例を示す図である。
図20に示すように、プレイヤ4は、モーション動画810Aを再生しながら、発話音声820Aを入力している。この発話音声820Aは、ユーザ名が「AAAAA」であるユーザ3(以下、ユーザ3A)宛の発話音声である。つまり、
図20の例において、プレイヤ4は、ステップS64にて、ユーザ3A(第1ユーザ)を選択し、該ユーザ3A宛の動作指図データを作成している。なお、ユーザ3Aが使用するユーザ端末100は、ユーザ端末100Aであるとする。
【0195】
発話音声820Aは、ユーザ3A宛の発話音声であるため、該ユーザ3Aがアバターオブジェクト610(換言すれば、プレイヤ4)に対して行った支援の内容に基づく発話音声となっている。具体的には、ユーザ3Aは、10Fというステージでのボス戦において、マガジンを投入し、その投入されたマガジンの銃弾でアバターオブジェクト610がボスに勝利している。このため、発話音声820Aは、「ボス戦でマガジンをプレゼントしてくれてありがとう!タイミングも完璧だったね!AAAAAさんのおかげでクリアできたよ!」という内容である。このように、発話音声は、ユーザ3がゲームにおいて行った支援の内容と、ユーザ3への感謝とを含むものであることが好ましい。
【0196】
ある局面において、プレイヤ4は、音声入力を開始する前、すなわち、第3操作を配信端末400へ入力する前に、ユーザ3宛の発話内容を作成する。別の局面において、ユーザ3宛の発話内容は、プロセッサ40が自動生成してもよい。また、プロセッサ40は、第2操作によって選択されたユーザ3に対応付けられたタグを、モーション動画810Aに重畳して表示させてもよい。
【0197】
プロセッサ40は、受け付けた音声を音声データに変換する。ステップS68において、プロセッサ40は、動作指図データ生成部416として、該音声データと、選択されたモーションのモーションデータとを含む動作指図データを生成する。
【0198】
ステップS69において、プロセッサ40は、通信制御部411として、生成した動作指図データを選択されたユーザ3(
図20の例ではユーザ3A)のユーザ端末100(第1コンピュータ)に配信する。
図21は、配信端末400に表示される画面のさらなる別の具体例を示す図である。プロセッサ40は、ステップS68の実行後、表示制御部412として、配信画面を表示部452に表示させる。配信画面は、一例として、
図21(A)に示す配信画面751であってもよい。配信画面751は、UI画像752、および、モーション画像753Aを含む。また、配信画面751は、
図21(A)に示すように、動作指図データの配信先のユーザを示す情報を含むものであってもよい。
【0199】
UI画像752は、動作指図データを選択されたユーザ3へ配信するための操作を受け付ける。該操作は、例えば、UI画像752へのタップ操作であってもよい。モーション画像753Aは、生成した動作指図データに基づく動画、すなわち、ユーザ3A用に生成した動作指図データに基づく動画を再生するための操作を受け付けるUI画像である。該操作は、例えば、モーション画像753Aへのタップ操作であってもよい。なお、生成した動画を再生するための操作を受け付けるUI画像は、モーション画像753Aに限定されない。例えば、「動画再生」とのテキストを含むUI画像であってもよい。プロセッサ40は、動画が終了すると、自動的に配信画面751を再表示してもよい。
【0200】
配信画面751は、音声入力の受け付けに戻るための操作を受け付けるUI画像をさらに含むことが好ましい。該操作は、例えば、該UI画像へのタップ操作であってもよい。配信画面751が該UI画像を含むことにより、プレイヤ4は、例えば、発話する内容を間違えた場合など、音声入力に失敗した場合に、再度音声入力を行うことができる。なお、該UI画像は、モーションデータの選択に戻るための操作を受け付けるUI画像であってもよい。
【0201】
UI画像752に対するタップ操作を受け付けると、プロセッサ40は、ユーザ3Aを示す情報とともに、動作指図データをサーバ200へ送信する。サーバ200は、ユーザ3Aを示す情報に基づいて、動作指図データの送信先のユーザ端末100を特定し、該動作指図データを特定したユーザ端末100(すなわち、ユーザ端末100A)へ送信する。
【0202】
プロセッサ40は、動作指図データの送信が終了した場合、一例として、
図21(B)に示す配信完了画面761を表示部452に表示させてもよい。配信完了画面761は、一例として、UI画像762および763を含む。また、配信完了画面761は、
図21(B)に示すように、動作指図データの送信が完了したことを示すテキストを含むものであってもよい。
【0203】
UI画像762は、別のユーザ3宛の動作指図データの作成を開始するための操作を受け付ける。該操作は、例えば、UI画像762をタップする操作であってもよい。プロセッサ40は、該タップ操作を受け付けると、ユーザリスト画面を、表示部452に再度表示させる。すなわち、該タップ操作を受け付けた場合、配信処理は、ステップS63に戻る。このとき、プロセッサ40は、配信端末400に記憶したユーザリスト421に基づいて、ユーザリスト画面を生成し、表示部452に表示させてもよい。UI画像763は、アプリケーションを終了するための操作を受け付ける。該操作は、例えば、UI画像763をタップする操作であってもよい。該操作を受け付けると、配信処理は終了する。
【0204】
図20、
図21を参照して説明した例では、
図21(C)に示すように、配信端末400は、ユーザ3A(ユーザ名が「AAAAA」のユーザ3)宛の動画の動作指図データを、ユーザ端末100Aのみに送信する。
【0205】
図22は、プレイヤ4による音声入力の他の具体例を示す図である。
図22に示すように、プレイヤ4は、モーション動画810Bを再生しながら、発話音声820Bを入力している。この発話音声820Bは、ユーザ名が「BBBBB」であるユーザ3(以下、ユーザ3B)宛の発話音声である。つまり、
図22の例において、プレイヤ4は、ステップS64にて、ユーザ3Bに対応するレコード画像732Bへのタップ操作を入力し、ユーザ3B宛の動作指図データを作成している。なお、ユーザ3Bが使用するユーザ端末100は、ユーザ端末100Bであるとする。
【0206】
発話音声820Bは、ユーザ3B宛の発話音声であるため、該ユーザ3Bがアバターオブジェクト610(換言すれば、プレイヤ4)に対して行った支援の内容に基づく発話音声となっている。具体的には、ユーザ3Bは、3Fというステージのザコ敵との戦闘において、ユーザ「BBBBB」が救急箱を投入し、その結果、アバターオブジェクト610の体力が0になる(ゲームオーバーになる)寸前で体力が回復している。このため、発話音声820Bは、「BBBBBさんがプレゼントしてくれた救急箱のおかげで、3Fでゲームオーバーにならずにすんだよ。本当にありがとう!」という内容である。
【0207】
図23は、配信端末400に表示される画面のさらなる別の具体例を示す図である。
図23(A)に示す配信画面751は、UI画像752、および、モーション画像753Bを含む。モーション画像753Bは、タップ操作を受け付けると、ユーザ3B用に生成した動作指図データに基づく動画を再生する。
【0208】
UI画像752に対するタップ操作を受け付けると、プロセッサ40は、ユーザ3Bを示す情報とともに、動作指図データをサーバ200へ送信する。サーバ200は、ユーザ3Bを示す情報に基づいて、動作指図データの送信先のユーザ端末100を特定し、該動作指図データを特定したユーザ端末100(すなわち、ユーザ端末100B)へ送信する。
【0209】
図22、
図23を参照して説明した例では、
図23(C)に示すように、配信端末400は、ユーザ3B(ユーザ名が「BBBBB」のユーザ3)宛の動画の動作指図データを、ユーザ端末100Bのみに送信する。
【0210】
以上のように、動作指図データに含まれる音声データに基づく音声の内容は、ユーザ3が直近のゲームへの参加において、プレイヤ4に対して行った支援の内容に基づくものとなる。該支援の内容はユーザ3ごとに異なるため、音声の内容は、ユーザ3ごとに異なる内容となる。つまり、ゲームの終了後、ゲームに参加したユーザ3の少なくとも一部のユーザ端末100には、それぞれ異なる内容の音声を含む動作指図データが送信される。
【0211】
また、
図22の例におけるアバターオブジェクト610のモーションは、
図20の例におけるモーションと異なる。つまり、プレイヤ4は、ユーザ3B宛の動作指図データ生成において、ユーザ3A宛の動作指図データ生成時と異なるモーションデータを選択している。具体的には、プレイヤ4は、ステップS66において、レコード画像742Bに対応するモーションデータを選択する、UI画像745Bへのタップ操作を入力している。このように、プレイヤ4は、動作指図データに含まれるモーションデータを、ユーザ3毎に異ならせることができる。
【0212】
そして、ユーザ3毎に異なる内容の音声データと、ユーザ3毎に選択されたモーションデータとを含む、ユーザ3毎の動作指図データは、各ユーザ3のユーザ端末100のみに送信される。換言すれば、ユーザ端末100毎にユニーク(一意)の動作指図データが、選択されたユーザ3のユーザ端末100の各々に送信される。
【0213】
図24は、ゲームプレイ端末300からユーザ端末100へのゲーム進行情報の送信の概要を示す図である。ユーザ端末100における動画再生のための動作指図データが、ユーザ端末100毎にユニークである一方、
図24に示すように、ゲーム実行中に、ゲームに参加している全てのユーザ3のユーザ端末100に送信されるゲーム進行情報は、各ユーザ端末100の間で共通である。すなわち、ゲーム進行情報に含まれる動作指図データもまた、各ユーザ端末100の間で共通である。このように、動画再生のための動作指図データと、ゲームを進行させるための動作指図データとは、ユーザ端末100間での同異、および、送信先といった観点で異なるデータであると言える。
【0214】
(ユーザ端末100における動画再生処理)
図25は、ユーザ端末100で実行される動画再生処理の流れの一例を示すフローチャートである。
【0215】
ステップS71において、プロセッサ10は、動画再生部117として、動作指図データを受信する。ステップS72において、プロセッサ10は、動画再生部117として、動作指図データの受信をユーザ3へ通知する。プロセッサ10は、一例として、通知画像の表示部152への表示、スピーカ(不図示)からの通知音声の再生、LED(light-emitting diode)などで構成される点灯部(不図示)の点灯または点滅の少なくともいずれかにより、動作指図データの受信をユーザ3へ通知する。
【0216】
ステップS73において、プロセッサ10は、操作受付部111として、動画を再生するための第1再生操作を受け付ける。第1再生操作は、一例として、通知画像をタップする操作であってもよい。ステップS74において、プロセッサ10は、動画再生部117として、動作指図データをレンダリングし、動画を再生する。プロセッサ10は、一例として、本ゲームをプレイするためのアプリケーションを起動し、動画を再生してもよいし、該アプリケーションとは別の、動画再生用のアプリケーションを起動し、動画を再生してもよい。以降、該動画を、「ありがとう動画」と記載する。
【0217】
図26は、ありがとう動画の再生の一具体例を示す図である。具体的には、ユーザ3Aのユーザ端末100における、ありがとう動画の再生の一例を示す図である。該ユーザ端末100において再生されたありがとう動画910Aにおいて、アバターオブジェクト610は、或るモーションを実行しながら、音声920Aを発話している。換言すれば、プロセッサ10は、或るモーションを実行するアバターオブジェクト610を含むありがとう動画910Aを再生しながら、音声920Aをスピーカ(不図示)から出力させている。
【0218】
ありがとう動画910Aにおけるモーションは、ユーザ3A宛の動作指図データの生成において、プレイヤ4が選択したモーションデータに基づくものであり、音声920Aは、該動作指図データの生成において、プレイヤ4が入力した発話音声820Aから生成された音声データに基づくものである。つまり、音声920Aは、ユーザ3Aがゲームにおいて行った支援の内容と、該支援に対する感謝とを含む音声である。このように、ユーザ3Aは、第1再生操作の入力により、自身がゲームにおいて行った支援の内容と、該支援に対する感謝とを、アバターオブジェクト610が発話するありがとう動画を視聴することができる。
【0219】
ユーザ端末100は、一例として、ありがとう動画910Aの再生が終了した後、少なくとも1つのUI画像をタッチスクリーン15に表示させてもよい。該UI画像は、例えば、ありがとう動画910Aをもう一度再生するための操作を受け付けるUI画像であってもよいし、別の画面に遷移するための操作を受け付けるUI画像であってもよいし、アプリケーションを終了するための操作を受け付けるUI画像であってもよい。
【0220】
また、ユーザ端末100は、一例として、ありがとう動画910Aの再生中に、少なくとも1つのUI画像をタッチスクリーン15に表示させてもよい。該UI画像は、例えば、再生中のありがとう動画910Aを一時的に停止させたり、終了させたり、再生する場面を変更させたりする操作をそれぞれ受け付ける、複数のUI画像であってもよい。
【0221】
なお、ありがとう動画910Aの再生中、および、ありがとう動画910Aの再生が狩猟した後に表示されるこれらのUI画像には、アバターオブジェクト610に対する返答を行うためのUI画像は含まれない。すなわち、本実施形態に係るありがとう動画910Aにおいては、アバターオブジェクト610に対する返答を行うための手段が備えられていない。
【0222】
図27は、ありがとう動画の再生の他の具体例を示す図である。具体的には、ユーザ3Bのユーザ端末100における、ありがとう動画の再生の例を示す図である。該ユーザ端末100において再生されたありがとう動画910Bにおいて、アバターオブジェクト610は、或るモーションを実行しながら、音声920Bを発話している。換言すれば、プロセッサ10は、或るモーションを実行するアバターオブジェクト610を含むありがとう動画910Bを再生しながら、音声920Bをスピーカ(不図示)から出力させている。
【0223】
ありがとう動画910Bにおけるモーションは、ユーザ3B宛の動作指図データの生成において、プレイヤ4が選択したモーションデータに基づくものであり、音声920Bは、該動作指図データの生成において、プレイヤ4が入力した発話音声820Bから生成された音声データに基づくものである。このため、
図27の例において、アバターオブジェクト610が行っているモーションは、
図26の例のモーションとは異なる。また、音声920Bは、ユーザ3Bがゲームにおいて行った支援の内容と、該支援に対する感謝とを含む音声である。このため、
図27の例において、音声920Bの内容は、
図26の例に
おける音声920Aの内容とは異なる。
【0224】
このように、ゲームの終了後に、ゲームに参加したユーザ3の少なくとも一部のユーザ端末100が受信するありがとう動画は、ユーザ3毎にアバターオブジェクト610の発話内容が異なる動画である。
【0225】
なお、プロセッサ10は、次回のゲームへの参加を促す内容を含むUI画像930を、動画910に重畳させて表示させてもよい。UI画像930は、動作指図データとともに配信されてもよいし、ゲーム情報132として、ユーザ端末100が記憶していてもよい。
【0226】
ライブ配信ゲームにおいて、ゲームプレイ端末300により規定される仮想空間600Aと同じ仮想空間600Bがユーザ端末(視聴端末、端末装置)100により規定される。ゲームプレイ端末300は、演者の動きと演者の発話音声を特定可能な動作指図データを含むゲーム進行情報をサーバ200を介して複数のユーザ端末100に配信する。ユーザ端末100のメモリ11には、アバターオブジェクト610を含むオブジェクトを表示するための複数種類のオブジェクトデータが予め記憶されている。ライブ配信ゲームを開始するための操作が行われると、ユーザ端末100は、ゲームプレイ端末300からサーバ200を介して配信されたゲーム進行情報から動作指図データを特定し、当該動作指図データを解析(レンダリング)することにより、オブジェクトの種類・位置・姿勢等を特定する。また、ユーザ端末100は、当該解析結果に基づき、メモリ11に記憶されているオブジェクトデータを用いて、アバターオブジェクト610を含むオブジェクトを仮想空間600Bに配置する。
【0227】
HMD500のモニタ51には、仮想空間600Aに配置されている仮想カメラ620Aの位置、向き、および傾きに応じた視界領域640Aの視界画像650が表示される。また、ユーザ端末100のタッチスクリーン15には、仮想空間600Bに配置されている仮想カメラ620Bの位置、向き、および傾きに応じた視界領域640Bの視界画像660が表示される。ユーザ端末100が備える不図示のスピーカからは、ゲーム進行情報から特定した動作指図データに基づいて、演者の発話音声が出力される。
【0228】
<ゲームの概要>
本実施形態に係るシステム1により提供可能なゲームは、例えばライブゲーム期間の前後に割り当てられたライブ配信期間に行うライブ配信パートと、ライブゲーム期間に行うライブゲームパートとを含む。ライブ配信パートは、ユーザとアバターオブジェクト610との間において対話等のインタラクションを行うことが可能なパートである。一方、ライブゲームパートは、ユーザと演者との間において所定のゲームを行うことが可能なパートである。本実施形態に係るシステム1により提供可能なゲームは、ライブ配信パートやライブゲームパートを含む複数種類のパートから構成されており、配信側において予め定められた順および演者の進行具合いに応じてパートが移行されることにより進行する。ライブ配信中においてはライブ配信パート中およびライブゲームパート中のいずれにおいても、ユーザ(視聴者)は、アバターオブジェクト610の状況等を確認しつつ、アイテム投入やコメント入力等を適切なタイミングで行うことができる。例えば、ユーザからのタッチ操作に応じて、ユーザにより指定されたアイテム(以下、投げ銭アイテムともいう)のオブジェクトをアバターオブジェクト610が配置されている仮想空間内に配置あるいは表示(反映)できる。これにより、ユーザの存在・貢献等を演者や他のユーザに対してアピールでき、ゲームの興趣を向上させることができる。
【0229】
システム1により提供可能なゲームは、ゲームプレイ端末300側から一斉配信されるゲーム進行情報に基づいて、ユーザ端末100側で仮想空間を生成して演者の動きに応じてアバターオブジェクト610を動作させる映像を表示する。ゲームプレイ端末300側から一斉配信された同じゲーム進行情報であっても、ユーザ端末100側の通信状態(通信において突発的あるいは一時的に生じた不具合)等に応じてユーザ端末100間においてライブ映像の表示タイミングにズレ(遅延)を生じさせてしまう。ズレ(遅延)が生じた場合には、ライブ映像等が演者や他のユーザとズレるため、前述したアイテム投入やコメント入力等を適切なタイミングで行うことができず、効果的にアピールすることが不可能となる。そこで、本実施形態においては、ゲームを構成するあるパート(第1のパート)から次のパート(第2のパート)に移行する際にトランジションとして転換画面(特定映像)をある程度の期間に亘って表示するためのゲーム進行情報を配信し、当該特定映像を表示している間に遅延しているユーザ端末100においても現在パートの終了タイミングに到達し得ることによりズレ(遅延)を吸収(リセット)でき、次のパートの映像を視聴しているすべてのユーザ端末100間においてほぼ同じタイミングで開始可能となる。これにより、前述したようにアバターオブジェクト610の状況等に応じてユーザによりアイテム投入やコメント入力等を適切なタイミングで行うことができ、演者や他のユーザに対してアピール等を行うことができる。以下において、
図28および
図29を用いて具体例を説明する。
図28は、ライブ配信中のユーザ端末100のタッチスクリーン15における表示例を示している。
図29は、複数のユーザ端末100間における映像のズレを説明するためのタイミングチャートである。
【0230】
(ライブ配信パート:第1のパートの一例)
演者がコントローラ540によりライブ配信開始操作を行うと、ゲーム進行情報の配信(ライブ配信)が開始される。ここでは、ライブ配信開始時においては、ライブ配信パートが開始される例について説明する。ゲームプレイ端末300は、当該ライブ配信パートにおいて、仮想空間600Aをライブ配信空間として規定し、ワンピースを着用した女の子を模したアバターオブジェクト610や、「御宴会」と書かれた横断幕および山を模した装飾オブジェクト(背景オブジェクト)を含む仮想オブジェクトを当該ライブ配信空間に配置する(ユーザ端末100側の表示例である
図28(A)等参考)。ゲームプレイ端末300は、HMD500およびモーションセンサ520の各々からの出力に基づいて演者の身体の動きを検出し(即ち、演者のモーションをキャプチャし)、これによって生成されたモーションデータ等に基づいて、アバターオブジェクト610を含む仮想オブジェクトを当該ライブ配信空間内において配置・動作等させる。また、ゲームプレイ端末300は、当該モーションデータや音声データ等に基づいて、アバターオブジェクト610や装飾オブジェクトを含む仮想オブジェクトの配置・動作・発話等を特定可能にするための動作指図データを生成し、当該動作指図データを含むゲーム進行情報を複数のユーザ端末100に配信する。
【0231】
複数のユーザ端末100の各々は、ライブ配信パートにおいて、仮想空間600Bをライブ配信空間として規定し、当該ライブ配信空間の所定位置(例えば、アバターオブジェクト610を正面から捉えることが可能な位置)に仮想カメラ620Bを配置する。ユーザ端末100は、メモリ11に予め記憶されているモデルデータと、ゲームプレイ端末300から配信されたゲーム進行情報とに基づいて、アバターオブジェクト610や装飾オブジェクトを含む仮想オブジェクトをライブ配信空間に配置し、または既に配置されている仮想オブジェクトを動作させる。また、ユーザ端末100は、現在の仮想カメラ620Bの位置および向きに応じた視界領域640Bを規定し、当該視界領域640Bに対応する視界画像660をライブ配信映像としてタッチスクリーン15に表示する(
図28(A)および
図28(B)参照)。ゲームプレイ端末300側から配信されるゲーム進行情報は、所定時間毎に、複数のユーザ端末100に対して一斉に配信される。これにより、ゲームプレイ端末300及び複数のユーザ端末100各々の間で、少なくとも演者の動きに応じたアバターオブジェクト610の動作や演者の発話内容等を共有でき、所定時間毎に更新・出力される。
【0232】
一方で、ゲーム進行情報に基づく映像をタッチスクリーン15に表示する実際のタイミングは、ユーザ端末100各々の通信状態(例えば、通信速度、通信の安定性等)の影響により、複数のユーザ端末100間において異なり得る。その結果、ゲームプレイ端末300側からゲーム進行情報が一斉に配信されても、当該ゲーム進行情報に基づく映像がタッチスクリーン15に表示されるタイミングについては、複数のユーザ端末100間において異なることとなる(ズレが生じ得る)。
【0233】
図29(A)は、ゲームプレイ端末300側からゲーム進行情報が配信されてから、当該ゲーム進行情報に対応する映像がユーザA~C所有のユーザ端末100各々に表示されるタイミングの一例を説明するための図である。
図29(A)の上方から、ゲームプレイ端末300(配信側)から所定時間毎に配信されるゲーム進行情報が示され(下向き矢印「↓」および「…」)、下方のユーザA~C各々に対応して受信したゲーム進行情報に基づく映像がユーザA~C所有のユーザ端末100各々に表示されるタイミングが示されている。なお、「…」は、所定時間毎にゲーム進行情報が配信されていることを示している。また、
図29(A)の下欄の丸付き数字は、タイミング1~13を示している。なお、ゲーム進行情報が一斉配信されてからユーザ端末100が当該ゲーム進行情報を受信して対応する映像を表示するまでには、正常な通信状態(視聴開始から突発的あるいは一時的な不具合が生じていない場合など)で受信したとしても受信時間やユーザ端末100における画像処理等に時間を要するため若干の遅れが生じる。しかし、
図29を含む本実施形態では、正常な通信状態で受信した場合に生じる若干の遅れについては便宜上無視して説明することとし、配信されたゲーム進行情報を正常な通信状態で受信した場合には当該配信されたタイミングで当該ゲーム進行情報に基づく映像を表示するものとする。
【0234】
図29(A)では、ユーザA~C所有のユーザ端末100各々の通信状態などの影響(視聴開始から突発的あるいは一時的な不具合が生じた場合など)により遅れが生じている例を示している。例えば、ゲームプレイ端末300側からタイミング1において配信されたゲーム進行情報αに基づく映像は、ユーザAのユーザ端末100においてはタイミング2(タイミング1からの遅れa)において表示され、ユーザBのユーザ端末100においてはタイミング3(タイミング1からの遅れb)において表示され、ユーザCのユーザ端末100においてはタイミング4(タイミング1からの遅れc)において表示されている。また、ゲームプレイ端末300側からタイミング5において配信されたゲーム進行情報βに基づく映像についても同様に、ユーザAのユーザ端末100においてはタイミング6(タイミング5からの遅れa)において表示され、ユーザBのユーザ端末100においてはタイミング7(タイミング5からの遅れb)において表示され、ユーザCのユーザ端末100においてはタイミング8(タイミング5からの遅れc)において表示されている。
【0235】
ライブ配信期間においては、演者から視聴者(ユーザ)に対して、例えば所定の会話(挨拶、身近であった出来事の報告など)や、次のパートの予告・説明(例えば、ライブゲームが開始される旨や、ライブゲームの概要説明など)が行われる。演者は、ライブ配信パートにおいて説明等が完了したときに、コントローラ540に対して次のパートに移行させるためのパート移行操作(所定のボタン操作等)を行う。ゲームプレイ端末300は、パート移行操作を検出すると、現在のパートを終了させて次のパートの準備に移るためのパート終了情報を含むゲーム進行情報を出力する。
【0236】
ユーザ端末100側においては、パート終了情報を含むゲーム進行情報を受信して、当該ゲーム進行情報に基づく表示を開始するときに仮想カメラ620Bの位置および向き(すなわちユーザ毎の視界領域640B)にかかわらず、タッチスクリーン15の全表示領域に亘って予め定められた転換画面を表示する(
図28(C)参照)。これにより、パートを移行するための処理が行われていることをユーザにわかりやすく報知できる。転換画面を表示するための表示用データは、当該ゲームプログラムをダウンロードした際や更新タイミングにおいて、ユーザ端末100のメモリ11に予め記憶されている。
図28(C)においては、転換画面として、背景として所定の模様が表示されるとともに、3人のキャラクタ各々が所定のアクションを取っている静止画像が例示されている。なお、転換画面は、静止画像に限らず、所定の動画像であってもよい。また、転換画面の種類は、ユーザ端末100毎に予め設定可能であり、ユーザ端末100毎に設定された種類の転換画面が表示されるものであってもよい。
【0237】
図29(A)のタイミング9は、ゲームプレイ端末300からパート終了情報を含むゲーム進行情報が配信されたタイミングを示している。タイミング10~12は、各々、ユーザA~C所有のユーザ端末100において転換画面が表示されたタイミングを示している。このように、転換画面の表示が開始されるタイミングは、それ以前から生じていたズレ(遅れ)に応じて複数のユーザ端末100間において異なる(タイミング10~12参照)。一方、遅れが生じていたユーザA~C所有のユーザ端末100においては、正常な通信状態であれば転換画面が表示され得る間(具体的にはタイミング9~13に到達するまで)において、パート終了情報を含むゲーム進行情報以前に受信してバッファに記憶しているゲーム進行情報に基づいてライブ配信パートの未表示部分の映像・発話内容を出力して、当該ライブ配信パートの最後まで出力した後に転換画面が表示されることとなる。
【0238】
演者は、パート移行操作を行ってから、次のパートのライブ配信のための準備や段取り・進行の再確認等を行う。ここでは、次のパートとしてライブゲームパートが行われる例について説明する。ゲームの種類としてジャンケンゲームを例示する。次のパートの準備等が整うと、演者は、コントローラ540に対して、次のパートを開始させるためのパート開始操作(所定のボタン操作等)を行う。ゲームプレイ端末300は、パート開始操作を検出すると、転換画面表示を終了させて次のパートを開始させるためのパート開始情報を含むゲーム進行情報を一斉に配信する。パート開始情報を含むゲーム進行情報を受信したユーザ端末100は、転換画面を表示していた表示時間等にかかわらず、当該受信したタイミングで転換画面から当該ゲーム進行情報に基づく映像に切り替えて表示する。
【0239】
図29(A)のタイミング13は、ゲームプレイ端末300からパート開始情報を含むゲーム進行情報が配信され、ユーザA~C所有のユーザ端末100各々において正常な通信状態で受信して当該ゲーム進行情報に基づく映像・発話内容が出力されたタイミングを示している。タイミング13においてゲーム進行情報が配信された際に、正常な通信状態(視聴開始から突発的あるいは一時的な不具合が生じていない場合など)で当該ゲーム進行情報を受信できた場合には、ユーザ端末100間において同時(あるいは端末の処理能力・性能の差を考慮してほぼ同時)に当該ゲーム進行情報に基づく映像・発話内容が出力される。これにより、転換画面が表示されるまでにおいて遅延していたユーザ端末100についても、他のユーザ端末100とほぼ同じタイミングで次のパートの映像を表示できる。つまり、遅延が生じていた場合であっても、配信内容を損なうことなく転換画面表示中においてその遅延を吸収(リセット)でき、複数のユーザ端末100各々において、パート開始情報を含むゲーム進行情報を受信したタイミングで次のパートの映像を表示可能となる。具体的には、ライブ配信される映像・発話内容等を途中で強制終了させることなく最後まで出力可能としつつ、遅れが生じていたユーザA~C所有のユーザ端末100を含む複数のユーザ端末100において表示映像・発話内容を同期させることができる。これにより、ライブゲームパートにおいてアバターオブジェクト610の状況等に応じてユーザによりアイテム投入やコメント入力等を適切なタイミングで行うことができ、演者や他のユーザに対してアピール等を行うことができる。
【0240】
また、前述したように、パート移行操作を行ってからパート開始操作を行うまでの間は、演者が次のパートのライブ配信のための準備や段取りの再確認等を行うため、ある程度の時間を要することが見込まれる。本実施形態においては、このように次のパートに移行するまでに発生する時間を有効活用して、配信内容を損なうことなく転換画面を表示する間において複数のユーザ端末100における遅延を吸収し、次のパートの映像を複数のユーザ端末100間においてほぼ同じタイミングで表示(同期)させることができる。
【0241】
(ライブゲームパート:第2のパートの一例)
ジャンケンゲームのライブゲームパートでは、ゲームプレイ端末300側において規定される仮想空間600A内に、アバターオブジェクト610と、選択肢オブジェクト281~283とが配置され、花輪を想起させる花輪オブジェクトが背景として配置されているものとする(ユーザ端末100側の表示例である
図28(D)等参考)。仮想空間600Aには、その他のオブジェクトとして、アバターオブジェクト610の周囲を飾るオブジェクトや、視聴者に対応する視聴者オブジェクト、背景オブジェクト、床オブジェクトなどが配置されている。アバターオブジェクト610は、ライブゲームパートにおいても、演者のモーションに応じて動き、当該演者による音声を発話する。
【0242】
また、選択肢オブジェクト281~283は、各々、棒部と、先端の円板部とから構成されている。円板部の面には、グー・チョキ・パーを表すイラストが描かれている。選択肢オブジェクト281~283は、各々、プレイヤによる掴むモーションに応じて、棒部を掴むことができる。プレイヤにより選択肢オブジェクト281~283等を掴む操作(モーション)は、プレイヤの手に取り付けられて当該手の動き(手の動作(例えば、各指の位置、握りの形状・向き等)を検出するモーションセンサ520が設けられるコントローラ540により検知される。プレイヤは、選択肢オブジェクト281~283のうち、最終的に出す手(グー・チョキ・パー)に対応する選択肢オブジェクトを掴んで上方に掲げることにより、アバターオブジェクト610が出す手が確定されることになる。
【0243】
ゲームプレイ端末300は、ライブゲームパート中において、仮想空間600A内に配置されているオブジェクト(アバターオブジェクト610、選択肢オブジェクト281~283等)の位置、姿勢、向きなどを特定するための情報や音声データ(動作指図データ)などを含むゲーム進行情報を、所定時間毎に複数のユーザ端末100に向けてライブ配信する。なお、ゲームプレイ端末300から複数のユーザ端末100に向けて配信されるゲーム進行情報は、動作指図データのみならず、初期配置情報や、ゲーム情報132、配信時間、アバターオブジェクト610の出す手として確定した選択肢オブジェクトの種類(グー、チョキ、パー)、現在のパート・場面・期間を特定するための情報などが含まれる。これにより、ユーザ端末100側においては、仮想空間600Aと同様に、アバターオブジェクト610や、選択肢オブジェクト281~283、花輪オブジェクト284、視聴者オブジェクト、背景オブジェクトなどのオブジェクトが配置されている仮想空間600Bが規定される。また、ユーザ端末100側においては、当該仮想空間600B内においてゲーム進行情報に基づいてアバターオブジェクト610等を動作させて、ユーザからの入力操作に応じた位置等に配置されている仮想カメラ620Bからの視界画像をタッチスクリーン15に表示する。なお、ゲームプレイ端末300及び複数のユーザ端末100の間において共有するオブジェクトは、仮想空間600A内に配置されているオブジェクトのうち、少なくとも演者によりライブで演じられるアバターオブジェクト610を含むものであれば、アバターオブジェクト610のみでもよく、また、アバターオブジェクト610や選択肢オブジェクト281~283以外の他のオブジェクトを含むものであってもよい。
【0244】
ユーザ端末100側においては、パート開始情報を含むゲーム進行情報を受信したときに、転換画面から当該ゲーム進行情報に基づいて次のパートに対応する表示に切り替える。このときの仮想カメラ620Bの位置および向き(すなわちユーザ毎の視界領域640B)は、転換画面表示前の仮想カメラ620Bの位置および向きにかかわらず、アバターオブジェクト610を正面視する位置(所定位置)および向き(所定方向)が設定される。なお、新たなパートを開始するときの仮想カメラ620Bの位置および向きは、これに限らず、転換画面表示前の仮想カメラ620Bの位置および向きを引き継ぐものであってもよい。
【0245】
図28(D)~
図28(F)は、ジャンケンゲーム進行中におけるユーザ端末100のタッチスクリーン15の表示例を示す図である。
図28(D)~
図28(F)の例では、アバターオブジェクト610を正面視する位置に仮想カメラ620Bが配置されているものとする。このため、仮想カメラ620Bからの視界画像として、
図28(D)に例示されるように、タッチスクリーン15の略中央位置においてアバターオブジェクト610が起立している状態で表示されるとともに、当該アバターオブジェクト610を基準として当該アバターオブジェクト610の右前方に選択肢オブジェクト281~283が表示され、背後に花輪オブジェクト284などが表示される。
図28(E)におけるアバターオブジェクト610は、例えば「何を出そうかなー、どれにしようかなー」などと思案している様子(モーション)とともに音声が出力されているような場面を示している。
【0246】
また、ジャンケンゲーム進行中においては、各種のUI画像や、ゲーム情報に関する画像等がタッチスクリーン15に表示される。
図28(D)においては、例えば、選択用UI180、ルール説明表示181、アイテム投入用アイコン185、コメント入力用アイコン186などが仮想空間内の視界画像に重畳させて表示される。また、タッチスクリーン15の左下には、アバターオブジェクト610に宛てて入力されたコメント内容を表示するためのコメント表示部184が設けられている。
【0247】
ルール説明表示181は、ジャンケンゲームについてのルールを説明するための画像である。
図28(D)では、例えば、「・全部で3回戦!」「・制限時間内にボタンを押そう!」「勝ち50P」「あいこ10P」「負け0P」といったメッセージ等が表示されている。なお、タッチスクリーン15の左上には、ライブゲームパート中のどの場面(例えば、何回戦目)であるかを特定するための情報として、「1回戦目」といったメッセージが表示される。
【0248】
選択用UI180は、ユーザが出す手を選択するためのボタンアイコンを含み、当該ボタンアイコンへの入力操作(タップ操作)を受け付けるためのUIである。つまり、選択用UI180は、ジャンケンゲームの結果にかかわる操作を受け付けるためのUI画像であるといえる。
図28(D)の例では、選択用UI180は、アバターオブジェクト610を含む視界画像や、コメント表示部184、アイテム投入用アイコン185、コメント入力用アイコン186などよりも優先して表示される。
図28(D)では、「出す手を選ぼう!」といったメッセージが表示されるとともに、その下方において左側からグーに対応するボタンアイコン、チョキに対応するボタンアイコン、パーに対応するボタンアイコンが表示されている。これにより、ユーザは、直感的にボタンアイコンに対するタッチ操作により出す手を選択できることを認識可能となる。また、「出す手を選ぼう!」のメッセージの左側には、出す手を選択できる制限時間(受付期間ともいう。ここでは「10」)が表示され、当該メッセージの右側(選択用UI180内の右上)には、当該選択用UI180自体の表示を消去するための「×」ボタンが表示されている。なお、ジャンケンゲームは、選択用UI180が表示された状態で開始されるが、ユーザの初期設定により例えばゲーム開始時の選択用UI180の状態を非表示とするように設定されているときなどは、選択用UI180が表示されていない状態(
図28(I)で例示する画面等)で開始されるようにしてもよい。選択用UI180内に表示される制限時間は、演者の操作により操作の受け付けが開始されてから計時が開始(減算開始)される。
【0249】
ユーザは、出す手の選択(グー・チョキ・パーに対応するボタンアイコンへの入力操作)を終えていなくても、「×」ボタンを選択すること(「×」ボタンに対するタッチ操作等)で選択用UI180を消去することができる。これは、選択用UI180が表示されていると、
図28(D)等に示すように、選択用UI180でアバターオブジェクト610(キャラクタ)が隠れている場合には、ユーザからアバターオブジェクト610の画像が見えない(重畳部分については視認不可能となる)ためである。また、選択用UI180が表示されていると、
図28(D)等に示すように、コメント表示部184や、アイテム投入用アイコン185などが隠れてしまい、これらの画像が見えにくくなってしまい(重畳部分については視認不可能となる)、かつ操作し難い(あるいは操作できない)ためである。ユーザは、ユーザ自身の操作に応じて選択用UI180を消去することにより、当該選択用UI180により視認不可能であった画像を視認できる。
【0250】
アイテム投入用アイコン185は、アイテムを投入してアバターオブジェクト610に付与する契機となるアイコンである。アイテム投入用アイコン185への入力操作が受け付けられたときには、複数種類のアイテムから選択して投入するためのウィンドウが表示される。前述したように選択用UI180は、アイテム投入用アイコン185よりも優先して表示される。このため、選択用UI180がアイテム投入用アイコン185に重畳して表示されているときには、当該選択用UI180の表示を消さなければ、アイテム投入用アイコン185への入力操作を有効に受け付けないようにしてもよい。また、選択用UI180がアイテム投入用アイコン185に重畳して表示されているときであっても、当該選択用UI180の表示を維持したままの状態で、アイテム投入用アイコン185への入力操作を有効に受け付けるようにしてもよい。
【0251】
コメント入力用アイコン186は、アバターオブジェクト610に宛てにコメントを入力する契機となるアイコンである。コメント入力用アイコン186への入力操作が受け付けられたときには、コメントを入力して送信するためのウィンドウが表示される。なお、コメント入力用アイコン186については、選択用UI180が重畳して表示されることがない位置に表示されているが、アイテム投入用アイコン185と同様に、選択用UI180の表示を消さなければ、コメント入力用アイコン18への入力操作を有効に受け付けないようにしてもよい。また、選択用UI180が表示されているときであっても、当該選択用UI180の表示を維持したままの状態で、コメント入力用アイコン18への入力操作を有効に受け付けるようにしてもよい。コメント表示部184においては、アバターオブジェクト610宛てに入力されたコメントのうち新しいものから順に所定個数分のコメントがユーザ名とともに表示される。
【0252】
アイテム投入用アイコン185およびコメント入力用アイコン186は、各々、ユーザがアバターオブジェクト610との間でインタラクションを行うための入力操作を受け付けるアイコンであり、インタラクション画像であるともいえる。また、コメント表示部184は、ユーザがアバターオブジェクト610との間で行ったインタラクションの結果を表示するため、インタラクション画像であるともいえる。
【0253】
図28(E)は、ユーザが出す手を選択したときの表示例である。
図28(E)では、「グー」が選択された例を示す。「グー」が選択されると、
図28(E)に示されるように、選択用UI180内の「グー」のボタンアイコンが選択された状態(2重丸で囲われた状態)に更新される。なお、
図28(E)では、制限時間が「7」となっているため、ユーザは残り7秒を残して出す手を決定したことになる。これに対し、
図28(E)におけるアバターオブジェクト610については、選択肢オブジェクト281~283を掴んで、「どれにしようかなー、チョキかパーにしようかなー」などと思案している様子(モーション)とともに音声が出力されている場面が示されている。なお、ジャンケンゲームにおいてユーザにより選択された手は、メモリ11の所定領域に格納され、その後、制限時間内であれば再度ボタンアイコンへの操作を行うことにより出す手を変更することができる。また、出す手が選択された状態で選択用UI180が消去された場合であっても、選択された手を特定可能な情報はメモリ11において維持される。
【0254】
ジャンケンゲームにおいては、制限時間が経過した後に、演者が手を出す期間(以下、演者手出し可能期間ともいう)が予め設けられており、当該演者手出し可能期間内において、演者のタイミングで「ジャンケンホイ」などといった掛け声とともに、選択肢オブジェクト281~283のいずれか一つを上方に掲げて演者(アバターオブジェクト610)の手を出すことにより、ゲーム結果が報知される。
【0255】
図28(F)は、制限時間経過後においてアバターオブジェクト610の手を出したときの表示例である。
図28(F)では、アバターオブジェクト610により「チョキ」の選択肢オブジェクト282が掲げられている。これにより、アバターオブジェクト610が「チョキ」を出したことが報知される。アバターオブジェクト610が手を出したときには、アバターオブジェクト610の出す手として確定した選択肢オブジェクトの種類(グー、チョキ、パー)を特定するための情報を受信する。プロセッサ10は、当該情報に基づいて、ユーザが出した手と比較してユーザの勝敗を判定する。
図28では、ユーザが「グー」を選択していたため、ユーザの勝ちと判定される。その結果、アバターオブジェクト610の上方において「勝ち」といったメッセージが表示される。なお、ジャンケンゲームにおいてアバターオブジェクト610が出す手は、いずれのユーザに対しても同じとなるが、ユーザが選択する手についてはユーザ毎に異なる。このため、プレイヤが演じるアバターオブジェクト610等の動作は、複数のユーザ端末間において同じとなるが、ジャンケンゲームの結果については、ユーザの入力操作に応じて複数のユーザ端末間において異なるものとなる。
【0256】
演者は、同じパート中であってもある場面(1回戦分)が終了したタイミングにおいて次の場面に移行させるときに、コントローラ540に対して次の場面(次の回戦)に移行させるための場面移行操作(所定のボタン操作等)を行う。ゲームプレイ端末300は、場面移行操作を検出すると、現在のパートにおいて次の場面の準備に移るための場面終了情報を含むゲーム進行情報を出力する。
【0257】
ユーザ端末100側においては、場面終了情報を含むゲーム進行情報を受信することにより、パート移行時と同様に、当該ゲーム進行情報に基づく表示を開始するときに仮想カメラ620Bの位置および向き(すなわちユーザ毎の視界領域640B)にかかわらず、タッチスクリーン15の全表示領域に亘って転換画面を表示する(
図28(G)参照)。これにより、場面を移行するための処理が行われていることをユーザにわかりやすく報知できる。また、仮にジャンケンゲームの1回戦中においていずれかのユーザ端末100においてズレ(遅れ)が生じていた場合であっても、パート移行時と同様に、転換画面を表示している間において、パート終了情報を含むゲーム進行情報以前に受信してバッファに記憶されているゲーム進行情報に基づいてライブ配信パートの未表示部分の映像・発話内容を出力して、当該ジャンケンゲームの1回戦の最後まで出力した後に転換画面が表示されることとなる。
【0258】
演者は、パート移行時と同様に、場面移行操作を行ってから、次の場面のライブ配信のための準備や段取り・進行の再確認等を行う。次の場面の準備等が整うと、コントローラ540に対して、次の場面を開始させるための場面開始操作(所定のボタン操作等)を行う。ゲームプレイ端末300は、場面開始操作を検出すると、転換画面表示を終了させて次の場面を開始させるための場面開始情報を含むゲーム進行情報を一斉に配信する。場面開始情報を含むゲーム進行情報を受信したユーザ端末100は、転換画面の表示時間等にかかわらず、当該受信したタイミングで転換画面から当該ゲーム進行情報に基づく映像に切り替えて表示する。具体的に、演者は、ジャンケンゲームの1回戦終了時において場面移行操作を行ってから、2回戦目のための準備や段取り・進行の再確認等を行う。2回戦目の準備等が整うと、演者は、コントローラ540に対して、2回戦目を開始させるための場面開始操作を行う。これにより、転換画面が表示されるまでにおいて遅延していたユーザ端末100についても、他のユーザ端末100とほぼ同じタイミングで次の場面である2回戦目の映像を表示できる。つまり、仮に1回戦中において遅延が生じていた場合であっても、転換画面表示中においてその遅延を吸収(リセット)でき、複数のユーザ端末100各々において、場面開始情報を含むゲーム進行情報を受信したタイミングで次の場面である2回戦目の映像を表示可能となる。これにより、2回戦目においてアバターオブジェクト610の状況等に応じてユーザによりアイテム投入やコメント入力等を適切なタイミングで行うことができ、演者や他のユーザに対してアピール等を行うことができる。
【0259】
図28(H)は、場面開始情報を含むゲーム進行情報に基づいてジャンケンゲームの2回戦目が開始されたときのタッチスクリーン15における表示例を示している。場面移行操作を行ってから場面開始操作を行うまでの間は、演者が次の場面のライブ配信のための準備や段取りの再確認等を行うため、ある程度の時間を要することが見込まれる。本実施形態においては、同じパート中において次の場面に移行するまでに発生する時間を有効活用して、転換画面を表示する間において複数のユーザ端末100における遅延を吸収し、次の場面の映像を複数のユーザ端末100間においてほぼ同じタイミングで表示(同期)させることができる。なお、同じパート中において新たな場面が開始されたときの仮想カメラ620Bの位置および向き(すなわちユーザ毎の視界領域640B)については、パート移行時と異なり、転換画面表示前の仮想カメラ620Bの位置および向きを引き継ぐが、これに限らず、転換画面表示前の仮想カメラ620Bの位置および向きにかかわらず、アバターオブジェクト610を正面視する位置(所定位置)および向き(所定方向)が設定されるものであってもよい。
【0260】
図28(I)は、選択用UI180内の「×」ボタンへの入力操作が受け付けられたときのタッチスクリーン15の表示例を示す図である。
図28(I)は、
図28(D)と同様に、ジャンケンゲーム開始直後の残り制限時間が「10」秒で、出す手をユーザが未だ選択していない状態を示している。
【0261】
ジャンケンゲームにおいては、ジャンケンゲームを盛り上げるように演者はモーションや発話を行う傾向にある。また、特にジャンケンゲーム開始直後においては、他のユーザが出す手を選択する作業を行っている割合が高いため、アイテム投入用アイコン185への操作やコメントを入力することより、演者から応答(モーションや発話)を得られる割合が比較的高くなる。しかし、
図28(D)の例では、選択用UI180がアバターオブジェクト610に重畳して表示されており、アバターオブジェクト610の一部の動きを視認できないため、仮に応答があったとしても視認できない可能性がある。なお、仮想カメラ600Bの位置および向き等によっては、選択用UI180がアバターオブジェクト610に重畳しない場合も生じ得るが、逆に選択用UI180がアバターオブジェクト610の顔部分や体部分、あるいは全体に重畳してしまう場合も生じ得る。また、ジャンケンゲームでは、仮想カメラ600Bの位置等にかかわらず、
図28(D)に示すように、選択用UI180がアイテム投入用アイコン185やコメント入力用アイコン186に重畳して表示されるため、ユーザがアバターオブジェクト610との間でインタラクションを行い難くまた応答を確認し難い状況となる。
【0262】
このような状況を考慮し、本実施形態におけるゲームでは、ゲームの結果にかかわる操作を受け付けていないときであっても、選択用UI180内の「×」ボタンへの入力操作により、当該選択用UI180を消去可能としている。
図28(I)は、
図28(D)などの状況において、選択用UI180内の「×」ボタンがタッチ操作されて、選択用UI180が消去されたときのタッチスクリーン15の表示例を示している。これにより、選択用UI180により視認できなかったアバターオブジェクト610や、アイテム投入用アイコン185やコメント入力用アイコン186が視認可能となる。その結果、ユーザ自身の操作によって、アバターオブジェクト610の動き(応答含む)を確認でき、かつインタラクションを行い易くかつ演者からの応答を確認し易い状況に変化させることができる。
【0263】
また、選択用UI180が消去されると、
図28(I)に示すように、再度、選択用UI180を表示するためのアイコン187(「ゲームに戻る」といったメッセージアイコン等)がタッチスクリーン15に表示される。アイコン187は、表示サイズが選択用UI180よりも小さく、かつ表示位置が選択用UI180よりも端側に寄った位置であって、他のアイコンのいずれとも重畳しない位置に表示される。このため、アイコン187によりアバターオブジェクト610を含む画像が視認できなくなること等による不都合の発生を防止できる。なお、残りの制限時間については、選択用UI180が消去されているときであってもタッチスクリーン15の所定領域(例えば、アイコン187内の領域)において表示するようにしてもよい。
【0264】
選択用UI180を消去した後においては、ユーザ自身によるアイコン187への操作に応じて選択用UI180を再度表示させて、ユーザの出す手を選択あるいは変更できる。また、プロセッサ10は、選択用UI180が消去している状態であっても、残りの制限時間に応じて自動的に選択用UI180を再度表示させる処理を行って、強制的にユーザの出す手を選択あるいは選択済の手を確認等させることができる。未だ出す手が選択されていないときには、いずれの手も選択されていない態様で選択用UI180を再表示する。これに対し、既に出す手が選択されているときには、当該手が選択されている態様で選択用UI180を再表示する。なお、出す手をユーザが制限時間内に選択しなかった場合、ユーザの出す手は自動的にランダムに決定されるものであってもよく、この場合、例えば、選択用UI180を再表示させるときに、自動的に決定された手が選択されている態様で選択用UI180を再表示するようにしてもよく、制限時間が終了したときに、自動的に決定された手が選択されている態様で選択用UI180を再表示するようにしてもよい。
【0265】
図28および
図29(A)では、パート移行時や場面移行時において、演者が次のパート等のための準備や段取りの再確認等を行うために要する時間(例えば、少なくとも5秒、あるいは10秒等)を有効活用して、現在のパートあるいは場面の最後まで出力した後に転換画面を表示し、パート開始情報または場面開始情報を受信したタイミングで転換画面から当該ゲーム進行情報に基づく映像に切り替えて出力する例について説明した。
【0266】
しかし、演者が次のパート等のための準備や段取りの再確認等を行うために要するであろう時間、すなわちパート移行操作~パート開始操作までに要する時間や場面移行操作~場面開始操作までに要する時間の平均的な時間を超えて遅れている場合には、転換画面表示中においてその遅延を吸収できない可能性が高い。このため、パート移行操作~パート開始操作までに要する時間や場面移行操作~場面開始操作までに要する時間の平均的な時間よりも短い時間を特定時間(例えば、5秒)として定め、ユーザ端末100においてライブ配信を視聴している際に、ゲーム進行情報が配信されてから当該ゲーム進行情報に基づく映像を表示するまでに要する時間が特定時間以上を要する状況であるか否かを判定し、特定時間以上を要する状況であると判定された場合には転換画面を強制表示させて特定時間以上に及ぶ遅延を吸収するような構成を備えるようにしてもよい。この場合、コントローラ540は、パート移行操作あるいは場面移行操作を受け付けてから少なくとも特定時間(5秒)が経過するまではパート開始操作あるいは場面開始操作を有効に受け付けないものであってもよい。ゲーム進行情報が配信されたタイミングは、例えば当該ゲーム進行情報に含まれる配信時間から特定される。このような例について、
図29(B)を参照して説明する。
【0267】
図29(B)は、ライブ配信中においてゲームプレイ端末300側からゲーム進行情報が配信されてから、当該ゲーム進行情報に対応する映像がユーザX所有のユーザ端末100に表示されるタイミングの一例を説明するための図である。
図29(B)では、ユーザX所有のユーザ端末100において遅延が発生している遅延未解消時のタイミングチャートと、その遅延を解消した遅延解消時のタイミングチャートとが示されている。
【0268】
図29(B)の遅延未解消時欄には、ユーザX所有のユーザ端末100について通信状態などの影響(視聴開始から突発的あるいは一時的な不具合が生じた場合など)により遅れが生じている例を示している。遅延未解消時欄においては、例えば、ゲームプレイ端末300側からタイミング1において配信されたゲーム進行情報θに基づく映像が、ユーザXのユーザ端末100においてはタイミング2(タイミング1からの遅れx)において表示される例を示している。ここで、遅れxは、前述の特定時間(例えば5秒)以上の時間とする。この場合、タイミング4においてパート終了情報を含むゲーム進行情報が配信されてから当該ゲーム進行情報に基づいて転換画面が表示されるタイミングは、遅延未解消時欄のタイミング6に示されるように、パート開始情報を含むゲーム進行情報が配信され得るタイミング5よりも後となり、転換画面表示中において遅れを吸収できない可能性がある。
【0269】
このように、ユーザ端末100側において遅れxが特定時間以上であると判定したときには、
図29(B)の遅延解消時欄のタイミング2に示されるように、ユーザ端末100は、転換画面を強制表示する。また、ユーザ端末100は、転換画面表示から予め定められた時間(例えば1秒等)経過後のタイミング3において受信したゲーム進行情報に基づいてライブ配信の映像に切り替えて表示する。これにより、ユーザX所有のユーザ端末100における遅れをライブ配信中に解消することができる。このように、ユーザ端末100は、遅延時間が特定時間以上となったときにはその都度遅延を解消するための処理を行う。その結果、ユーザ端末100は、タイミング4に示されるようにパート終了情報を含むゲーム進行情報が配信された場合であっても、当該配信から少なくともタイミング5に到達するまでの間に転換画面を表示できる。このため、パート開始情報を含むゲーム進行情報が配信されたタイミング5において次のパートの映像を表示可能とすることにより、他のユーザ端末100と同期させることができる。転換画面を表示する構成を備えることにより以下の効果を奏する。
【0270】
上記実施形態におけるユーザ端末100は、
図29(A)などに示すように、パート終了情報や場面終了情報を含むゲーム進行情報に基づいて現在のパートあるいは場面を終了するときに転換画面に切り替えて表示し(タイミング10~12参照)、パート開始情報や場面開始情報を含むゲーム進行情報を受信したときには、転換画面を表示していた時間(あるいは、パート終了情報を含むゲーム進行情報が配信されてからパート開始情報を含むゲーム進行情報が配信されるまでに要した時間)にかかわらず当該ゲーム進行情報に基づく映像・発話内容を出力する(タイミング13参照)。これにより、遅れが生じている場合であっても他のユーザ端末において転換画面を表示している間に現在のパートあるいは場面を最後まで出力でき、新たなパートあるいは場面が開始されるときにはゲーム進行情報を受信したときから次のパートあるいは場面の映像・発話内容を出力できる。その結果、現在のパートあるいは場面が途中で終了し唐突に次のパートあるいは場面が開始されることを極力回避できるため、配信品質に対する印象を極力低下させずかつ配信内容に違和感を生じさせてしまうことを極力防止できる。また、転換画面は、
図28(C)等で示すように、タッチスクリーン15の全表示領域に亘って所定の画像が表示される画面である。このため、転換画面を表示するための処理負担を軽減できる。
【0271】
また、パート終了情報や場面終了情報を含むゲーム進行情報は、コントローラ540に対するパート移行操作や場面移行操作を契機として一斉配信される。また、パート開始情報や場面開始情報を含むゲーム進行情報は、コントローラ540に対するパート開始操作や場面開始操作を契機として一斉配信される。一方、ユーザ端末100側においては、転換画面を表示している時間が、ゲームプレイ端末300側においてパート終了情報や場面終了情報を含むゲーム進行情報が配信されてからパート開始情報や場面開始情報を含むゲーム進行情報が配信されるまでに要する時間(すなわち転換画面が表示され得る時間)に達していないときでも、パート開始情報や場面開始情報を含むゲーム進行情報を受信したときに転換画面から当該ゲーム進行情報に基づく映像・発話内容を出力する。これにより、ユーザ端末100側において転換画面を表示する時間を管理する必要が無く、かつパート開始情報や場面開始情報を含むゲーム進行情報を受信したときの処理を一律にすることができるため、処理を簡易化できる。
【0272】
また、
図29(B)に示したように、ライブ配信中において遅延時間が特定時間以上となったときには、その時点で転換画面を表示した後、当該転換画面表示中に受信したゲーム進行情報に基づく映像・発話内容を出力する。これにより、過度な遅れが生じている場合には、ライブ配信中において転換画面を表示して同期を図ることができる。
【0273】
また、特定時間は、パート移行操作~パート開始操作までに要する時間や場面移行操作~場面開始操作までに要する時間に応じて定められる時間であって、パート移行操作~パート開始操作までに要する平均的な時間や場面移行操作~場面開始操作までに要する平均的な時間よりも短い時間が定められている。これにより、パート終了情報や場面終了情報を含むゲーム進行情報に基づく転換画面表示中において吸収できない可能性が高い遅れをライブ配信中に前もって同期させることができる。
【0274】
次に、ライブ配信を途中から視聴したときに関する処理内容を説明する。配信しているパートの内容によっては、途中から視聴を開始した場合に、当該ユーザが他のユーザよりも不利になる場合も考えられる。例えば、ライブゲームパートにおいてライブゲームが開始される直前において視聴を開始した場合には、当該ユーザがライブゲームを理解していないことやゲームに臨む準備ができていないことなどから、ゲームに参加したとしてもそれ以前から視聴していたユーザよりも不利となり得る。そこで、本実施形態においては、ライブゲームパート(特定パート)の途中からライブ配信の視聴を開始した場合であって、そのタイミングが当該ライブゲームパートのうちゲームに参加したとしても不利になり得る期間中であるときには、所定タイミング(例えば次の対戦を行う場面が開始されるタイミング)まで参加待機を促す待機情報を表示する。以下において、
図30を用いて具体例を説明する。
図30(A)は、ジャンケンゲームパートのうち一つの場面(例えば1回戦)が開始されてから結果報知までのゲーム進行に関して予め定められているスケジュール例を説明するための図であり、
図30(B)~
図30(E)は、ライブ配信を途中から視聴した場合のユーザ端末100のタッチスクリーン15における表示例を説明するための図である。
【0275】
図30(A)に示すように、ジャンケンゲームの1回戦分が開始されると、まず、所定の会話(挨拶、身近であった出来事の報告、前回ゲームの成績・感想など)や、次のパートの予告・説明(例えば、ライブゲームが開始される旨や、ライブゲームの概要説明など)を行う「会話・説明等の期間」となる。その後、ユーザからの操作を受け付ける「操作受付期間」となり、操作受付期間終了後においては「演者手出し可能期間」となり、最後に結果についての報告を行う「結果期間」となるように大まかにスケジュールが予め決められている。「操作受付期間」においては、演者が出す手のヒントや出す手に関連する情報などを話した後に、前述したように10秒間に亘って操作を受け付ける期間となる。このようなスケジュールに従って演者は、ジャンケンゲームを進行する。具体的に、演者は、コントローラ540に対して操作を行うことにより、「会話・説明等の期間」から「操作受付期間」に移行させ、「操作受付期間」から「演者手出し可能期間」に移行させ、「演者手出し期間」から「結果期間」に移行させる。つまり、パート移行や場面移行と同様に、演者のタイミングで各期間に移行させることができる。
【0276】
また、上記期間のうち、例えば、「会話・説明等の期間」は、未だ演者が出す手のヒントなどについて話されないため、どのタイミングで視聴を開始したとしてもすでに視聴しているユーザとの間における有利度に差を生じさせる可能性が低い。一方、「操作受付期間」は、演者が出す手のヒントなどについて話した後などであり、視聴していたユーザよりも不利となる可能性があり、また、操作受付期間の残り時間が短い場合などにも不利となってしまう。また、「演者手出し可能期間」や「結果期間」においては、すでに今回の回戦が終了しているため、途中参加自体が不可能である。このようにライブゲームパートの途中から視聴を開始したユーザの有利度合いは、どの期間からの視聴であるかに応じて異なることになる。
【0277】
そこで、本実施形態におけるユーザ端末100では、ライブ配信の視聴を途中から開始した場合にユーザにとって不利となり得る期間であるか否かを判定し、不利となり得る期間であるときには当該期間に対応する情報を報知する処理を行う。本実施形態におけるライブゲームパートでは、
図30(A)に示すように、「会話・説明等の期間」は参加可能期間に定められており、「操作受付期間」~「結果期間」は参加不可能期間に定められているものとする。具体例について、
図30(B)~
図30(E)を用いて説明する。
【0278】
図30(B)は、配信されているライブの視聴を開始するためのアイコンB1がタッチスクリーン15に表示されているときの表示例である。タッチスクリーン15の上方には、「ライブゲーム配信中」といったメッセージがスクロール表示され、画面中央に「ライブ視聴開始」と記載されたアイコンB1が表示されている。これにより、現在、ライブゲームパートの配信中であり、アイコンB1をタッチ操作することによりライブゲームパートを途中から視聴(参加)できることをユーザに報知できる。アイコンB1をタッチ操作すると、当該タッチ操作を契機として、
図30(C)に示されるように転換画面が一律に表示される。これにより、視聴開始操作を有効に受け付けてライブ視聴のための処理が行われていることをユーザにわかりやすく報知できる。
図30(C)における転換画面は、パート移行時等に表示される転換画面と同じ画面である例を示しているが、これに限らず、パート移行時等に表示される転換画面と異なる画面であってもよい。
【0279】
図30(D)および
図30(E)は、アイコンB1へのタッチ操作に応じてライブ配信される映像・発話内容が出力されたときの様子を示す図である。このうち、
図30(D)は、ライブゲームパートの「会話・説明等の期間」中(例えば
図28(D)等)に視聴を開始したときの表示例を示している。より具体的には、受信したゲーム進行情報に基づいて映像が表示される。
図30(D)では、ジャンケンゲームに関連する話やルール説明などを行っている様子が示されている。
【0280】
これに対し、
図30(E)は、ライブゲームパートのうち「操作受付期間」中(例えば
図28(E)等)に視聴を開始したときの表示例を示している。ユーザ端末100は、ライブ配信の視聴開始に伴って受信したゲーム進行情報から、現在の期間が「操作受付期間」以降の参加不可能期間(参加したとしても不利になり得る期間)であるか否かを特定する。また、ユーザ端末100は、「操作受付期間」以降の参加不可能期間であるときには、受信したゲーム進行情報に基づく映像に重畳(当該映像よりも優先)させて、次の回戦まで待機を促す待機画像188が表示される。
図30(E)では、待機画像188として「ゲーム中…次のゲーム(2回戦開始)まで、待っててね!」といったメッセージをスクロール表示させる画像が示されている。これにより、途中から視聴を開始した場合にユーザにとって不利となることを防止でき、かつ所定タイミング(例えば2回戦目を行う場面が開始されるタイミング)から参加可能であることをユーザにわかりやすく報知できる。一方、「会話・説明等の期間」中から視聴を開始したときには
図30(D)に示すように待機画像188が表示されないため、途中視聴した場合に常に待機画像が表示されて煩わしい印象をユーザに抱かせてしまうことを防止できる。
【0281】
また、
図30(E)では、ユーザがジャンケンゲームに参加できないため、選択用UI180が非表示となっている。これに対して、ルール説明表示181、アイテム投入用アイコン185、コメント入力用アイコン186については、
図30(D)と同様に表示される。これにより、参加不可能期間であっても、ルールを事前に確認することができる。また、アイテム投入やコメント入力等は、ユーザにとって不利を生じさせることがないため、途中視聴したユーザの意思に応じて実行可能となる。なお、1回戦目が終了して次の2回戦目を行う場面が開始されると、ユーザがジャンケンゲームに参加可能となるため、選択用UI180についても表示される(
図28(H)参照)。
【0282】
本実施形態のライブ配信ゲームでは、仮想空間600Bにアバターオブジェクト610が配置される。ゲームプレイ端末300(サーバ200)は、演者が入力した発話音声およびモーションに応じた音声データおよびモーションデータを含むゲーム進行情報を、複数のユーザ端末100に対して一斉にライブ配信する。複数のユーザ端末100各々は、受信したゲーム進行情報のうち、音声データの再生に合わせて、当該再生した音声データに対応するモーションデータを再生して、アバターオブジェクト610の表示状態を制御する。
【0283】
ライブ配信ゲームにおいては、ゲームプレイ端末300により規定される仮想空間600Aと同じ仮想空間600Bが、ユーザ端末100により規定される。ゲームプレイ端末300は、ヘッダと、動作指図データと、仮想空間制御データとを含むゲーム進行情報(
図31(A)参照)を、サーバ200を介して複数のユーザ端末100に配信する。動作指図データには、演者の発話音声に応じた音声データと、演者のモーションに応じたモーションデータとが含まれる。また、仮想空間制御データは、仮想空間600B内の進行を制御するためのデータであり、具体的には、仮想空間600Bに配置された各種オブジェクトを動作させるためのデータである。また、仮想空間制御データは、ゲーム情報132、アバターオブジェクト610の出す手として確定した選択肢オブジェクトの種類(グー、チョキ、パー)を特定するための情報なども含む。ユーザ端末100は、音声データを基準にしてモーションデータおよび仮想空間制御データを再生し、仮想空間600Bにおけるアバターオブジェクト610および各種オブジェクトの動きを制御する。
【0284】
ゲーム進行情報は、所定時間(例えば1/60秒)毎に配信され、当該所定時間内に配信されるゲーム進行情報が1フレームに相当する。即ち、音声データ、モーションデータおよび仮想空間制御データの各々は、フレーム単位のデータで構成されている。ヘッダには、フレームを識別するフレーム番号が含まれている。
【0285】
ライブ配信ゲームを開始するための操作が行われると、ユーザ端末100は、ゲームプレイ端末300からサーバ200を介して配信されたゲーム進行情報から音声データを特定し、当該音声データに基づいて入出力IF14に含まれるスピーカから演者の発話音声を出力する。
【0286】
ユーザ端末100のメモリ11には、アバターオブジェクト610を含むオブジェクトを表示するための複数種類のオブジェクトデータが予め記憶されている。また、メモリ11には、オブジェクトの種類を特定可能にするためのオブジェクトIDが記憶されている。
【0287】
ユーザ端末100は、ゲームプレイ端末300から配信されたゲーム進行情報からモーションデータと仮想空間制御データとを特定し、当該モーションデータおよび仮想空間制御データを解析(レンダリング)することにより、アバターオブジェクト610を含むオブジェクトの種類・位置・姿勢等を特定する。また、ユーザ端末100は、当該解析結果と、メモリ11に記憶されているオブジェクトデータおよびオブジェクトIDとに基づいて、アバターオブジェクト610を含むオブジェクトを仮想空間600Bに配置する。ユーザ端末100は、仮想空間600Bに配置されている仮想カメラ620Bの位置、向き、および傾きに応じた視界領域640Bの視界画像660を、タッチスクリーン15に表示する。
【0288】
ゲームプレイ端末300から配信された各フレームのゲーム進行情報に含まれる音声データ、モーションデータおよび仮想空間制御データは、メモリ11等に設けられているバッファメモリに入力される。ユーザ端末100は、音声データを受信した第1タイミングに基づいて、当該音声データの再生を開始する第2タイミングを特定し、バッファメモリに格納されている同じフレームの音声データ、モーションデータおよび仮想空間制御データ各々の再生を当該第2タイミングから開始する(
図31(B)参照)。第2タイミングは、前回受信した音声データの再生が終了するタイミングであってもよく、また、予め定められている時間が経過したタイミングなどであってもよい。再生が開始された後は、例えばプロセッサ10により管理されるシステム時間に基づいて当該再生を継続する。これにより、再生の際に、音声とモーションとを同期させることが可能となる。
【0289】
ただし、ユーザ端末100の周辺の通信環境の劣化(例えば、受信強度の低下や、ノイズの発生)等が原因で、音声データ、モーションデータおよび仮想空間制御データのうちのいずれかのデータが欠落または破損し、その結果、当該データを再生できない場合がある。
【0290】
そこで、ユーザ端末100は、あるフレームの音声データを再生できないときには、当該フレームに含まれているモーションデータおよび仮想空間制御データの再生をスキップする(
図32(A)のフレームm参照)。つまり、音声データを受信できていないときや再生できないときには、当該音声データに対応するモーションデータおよび仮想空間制御データを再生できる状況であったとしても、当該モーションデータおよび仮想空間制御データを再生しない。なお、
図32では、データを囲む枠を点線枠とすることにより、当該データを受信できていないあるいは再生できない状況であることを示している。
【0291】
これに対し、ユーザ端末100は、あるフレームの音声データは再生できる場合、当該フレームのモーションデータまたは仮想空間制御データを再生できない状況であっても、当該フレームのモーションデータまたは仮想空間制御データを再生できるときと同様に、当該フレームの音声データの再生を開始する(
図32(B)のフレームn+1参照)。つまり、音声データを受信して再生できるときには、当該音声データに対応するモーションデータおよび仮想空間制御データを再生できない状況であったとしても、当該音声データの再生を開始する。なお、音声データの再生を開始する際に、モーションデータおよび仮想空間制御データのうち再生可能なデータが存在する場合には、音声データの再生を開始するとともに、当該データの再生も開始する。
【0292】
図32(A)においては、フレームmのゲーム進行情報に含まれるモーションデータおよび仮想空間制御データについては受信できかつ再生できる状況である一方、音声データについては受信できていないか再生できない状況を示している。この場合、ユーザ端末100は、フレームmのモーションデータおよび仮想空間制御データの再生をスキップする。
図32(A)においては、再生をスキップするモーションデータおよび仮想空間制御データに「スキップ」の文字を付している。なお、次のフレームm+1のゲーム進行情報については正常に受信した場合には、当該ゲーム進行情報に含まれる音声データの再生を開始する第2タイミングを特定し、第2タイミングにおいて当該音声データを再生できる状況である場合には当該音声データを再生するとともに、当該音声データの再生を基点として、バッファメモリに格納されている同じフレームのモーションデータおよび仮想空間制御データ各々の再生を開始する。
【0293】
図32(B)においては、フレームn+1のゲーム進行情報に含まれるモーションデータおよび仮想空間制御データについては受信できていないか再生できない状況である一方、音声データについては受信できかつ再生できる状況を示している。この場合、ユーザ端末100は、当該フレームn+1の音声データの再生を開始する。なお、フレームn+1のゲーム進行情報に含まれるモーションデータおよび仮想空間制御データのうちのいずれか一方について受信できかつ再生できる状況においては、フレームn+1の音声データの再生を開始する第2タイミングから当該データの再生を開始する。
【0294】
本実施形態によれば、仮想空間600B内におけるアバターオブジェクト610を演じる演者が入力した音声およびモーションに応じた音声データおよびモーションデータがサーバ200から配信される。ユーザ端末100は、当該音声データの再生に合わせて、当該再生した音声データに対応するモーションデータを再生して、仮想空間600B内におけるアバターオブジェクト610の動作、即ち表示状態を制御する。これにより、音声データを基準として、当該音声データの再生に対応させてモーションデータを再生することにより、音声に合わせてキャラクタの表示状態を同期させることが可能となり、音声から離れてキャラクタの表示状態が制御されるなどといった視聴時に違和感が生じる不都合を極力回避することができる。
【0295】
また、本実施形態によれば、ユーザ端末100は、音声データを基準にしてモーションデータを再生するとともに、仮想空間600B内における他のオブジェクトの動き、即ち仮想空間600B内の進行を制御する。これにより、音声から離れて仮想空間600B内の進行が制御されるなどといった視聴時の違和感をさらに抑制することが可能となる。
【0296】
さらに、本実施形態によれば、ユーザ端末100は、音声データを受信した第1タイミングに基づいて、当該音声データの再生を開始する第2タイミングを特定し、再生した音声データに対応するモーションデータの再生を当該第2タイミングから開始する。これにより、演者が入力した音声を基準としてモーションの再生を確実に同期させることが可能となる。
【0297】
また、本実施形態によれば、音声データはフレーム単位のデータで構成されており、モーションデータもまたフレーム単位のデータで構成されている。ユーザ端末100は、音声データを構成する第1フレームの音声データを再生できないときには、モーションデータを構成する当該第1フレームのモーションデータの再生をスキップする(例えば、
図32(A)参照)。これにより、音声が出力されないままキャラクタの表示状態等が制御されてしまい、視聴時に違和感が生じる不都合が回避される。
【0298】
さらに、本実施形態によれば、ユーザ端末100は、音声データを構成する第2フレームの音声データは再生できるが当該第2フレームのモーションデータを再生できないときには、当該第2フレームのモーションデータを再生できるときと同様に、当該第2フレームの音声データの再生を開始する(例えば、
図32(B)参照)。これにより、演者の音声についてはユーザ側に極力提供でき、音声から配信されている内容等をユーザが認識・理解可能となる。
【0299】
本実施形態における音声データは、
図28(C)等で示した転換画面の表示にかかわるパート終了情報・パート開始情報を含む。また、音声データは、
図28(G)等で示した転換画面の表示にかかわる場面終了情報・場面開始情報を含む。さらに、音声データは、
図29(B)のタイミング2で示した転換画面の表示にかかわる配信時間を含む。これにより、ゲーム進行情報に基づく映像がユーザ端末100において表示される際には、音声データを再生可能な場合であるため、転換画面の表示を開始すべきタイミングで確実に表示開始でき、転換画面の表示を終了すべきタイミングで確実に表示終了できる。また、音声データは、
図30(D)に示す待機画像188の表示にかかわる現在のパート・場面・期間を特定するための情報を含む。これにより、ゲーム進行情報に基づく映像がユーザ端末100において表示される際には、音声データを再生可能な場合であるため、参加不可能期間において視聴を開始する場合に、待機画像を確実に表示できる。
【0300】
<変形例>
以上説明した実施形態の変形例などを以下に列挙する。
【0301】
(1) 上記実施形態におけるアバターオブジェクト610は、演者の頭部に装着されるHMD500が備えるセンサと、演者の両手、両足、腰部等に装着されるモーションセンサ520とにより検出された信号、即ちモーションデータに基づいて動作する例について説明した。しかし、アバターオブジェクト610は、演者の動きに応じて動作するものであれば、これに限らず、例えば、演者を複数のカメラを用いて演者を複数方向から撮影(キャプチャ)した画像を解析することにより演者の動きをゲームプレイ端末300側(配信側)において特定し、当該特定結果に基づいてアバターオブジェクト610を動作させるための動作指図データ(モーションデータを含むゲーム進行情報)を出力することにより、ユーザ端末100側において演者の動きに応じてアバターオブジェクト610を動作させる表示を行うものであってもよい。
【0302】
また、上記実施形態における演者は、頭部に装着しているHMD500に表示される映像から仮想空間内のオブジェクトを確認する例について説明した。しかし、演者が仮想空間内の画像を確認できるものであればこれに限らず、例えば、演者を取り囲むように(四方あるいは八方等)複数の表示部を配置し、当該表示部に当該演者から見た方向の仮想空間内の画像を表示するものであってもよい。この場合、演者は、周囲に配置されている複数の表示部に表示されている画像を見ることにより、仮想空間を確認できる。
【0303】
(2) 上記実施形態では、特定映像として転換画面を例示し、パート移行時に表示する転換画面(例えば、
図28(C))、場面移行時における転換画面(例えば、
図28(G))、および、遅延時間が特定時間以上であると判定されたときに表示する転換画面(例えば、
図29(B))は、いずれも同じ態様の画面である例について説明した。しかし、転換画面は、パート移行時、場面移行時、遅延時間が特定時間以上であると判定されたときのいずれであるかに応じて、異なる態様の画面が定められているものであってもよい。また、パート移行時の転換画面は、パート移行時であっても、移行前のパートあるいは移行後のパートの種類に応じて、異なる態様の画面が定められているものであってもよい。また、場面移行時の転換画面は、場面移行時であっても、移行前の場面あるいは移行後の場面の種類に応じて、異なる態様の画面が定められているものであってもよい。また、遅延時間が特定時間以上であると判定されたときに表示する転換画面は、パート移行時や場面移行時における転換画面と異なる態様の画面(例えば、「同期中…」といったメッセージ表示等)であってもよい。転換画面は、演者の動きに応じたアバターオブジェクト610をユーザが視認できない画像であれば
図28で示したものに限らず、例えば、タッチスクリーン15の表示を暗転(黒画面を表示)させた画面であってもよい。
【0304】
(3) 上記実施形態では、演者の操作に応じて転換画面の表示に関する情報(パート終了情報、パート開始情報等)を含むゲーム進行情報が配信され、転換画面が表示され得る時間が演者次第となる例について説明した。しかし、転換画面が表示され得る時間は、予め定められているもの(例えば、10秒等)であってもよい。この場合、ゲームプレイ端末300(配信側)においては、転換画面の表示を開始するための情報(パート終了情報等)を演者(配信側)の操作に応じて配信し、当該転換画面の表示を開始するための情報を配信してから予め定められた時間(例えば、10秒等)が経過したときに、転換画面の表示を終了するための情報(パート開始情報等)を自動配信するものであってもよい。また、転換画面が表示され得る時間は、パート移行時と場面移行時とで異なる時間が定められているものであってもよく、例えば、場面移行時の方がパート移行時よりも短い時間(例えば、5秒等)が定められているものであってもよい。
【0305】
(4) 上記実施形態における
図29(B)では、受信しているゲーム進行情報に基づく映像を表示するタイミング(例えばタイミング2)において、当該ゲーム進行情報の配信時間に基づいて配信から特定時間以上経過しているか否かを判定する例について説明した。しかし、判定方法は、これに限らず、例えば、受信しているゲーム進行情報に基づく映像を表示するタイミングにかかわらず、受信してバッファに記憶されており未だ出力されていないゲーム進行情報のうち最も古いゲーム進行情報の配信時間に基づいて配信から特定時間以上経過しているか否かを所定時間(例えば、1/60秒)毎に判定するものであってもよい。
【0306】
(5) 上記実施形態においては、選択用UI180を用いるゲームとして、ユーザが演者(アバターオブジェクト610)と対戦するゲームであって、選択用UI180は、対戦結果にかかわる操作(ユーザが出す手を選択するための手選択操作)を受け付ける例について説明した。しかし、対戦ゲームとしては、これに限らず、トランプゲーム(例えばポーカー等)であってもよい。また、選択用UI180を用いるゲームとしては、対戦ゲームに限らず、演者(アバターオブジェクト610)から出されたミッションをクリアすることを目指すゲームや、演者(アバターオブジェクト610)から提供されたゲームのスコアを競うゲームなどであってもよい。
【0307】
(6) 上記実施形態における演者が演じるアバターオブジェクト610を含む仮想空間内の画像は、外部から配信されるデータであってモーションデータおよび音声データを含む動作指図データを受信し、ユーザ端末100側において該動作指図データを用いて動画(映像)を生成(レンダリング)して再生する例(リアルタイムレンダリング方式)について説明した。しかし、ゲームプレイ端末300および配信端末400からは、アバターオブジェクト610を含む仮想空間内の動画を表示するための動画データを配信し、ユーザ端末100側において該動画データを用いてアバターオブジェクト610を含む動画(映像)を再生するもの(動画配信方式)であってもよい。つまり、リアルタイムレンダリング方式により、仮想空間600Bの画像をユーザ端末100に表示するものに限らず、複数フレームの画像により構成される動画データを配信する動画配信方式により、仮想空間600Bの画像をユーザ端末100に表示するものでもよい。
【0308】
(7) 上記実施形態におけるアバターオブジェクト610の表示態様は、例えば、ゲームの進行度合い(例えば、ジャンケンゲームで勝利する毎)に応じてユーザ毎に異なり得るようにしてもよい。例えば、ゲームプレイ端末300側から送信されるゲーム進行情報が同じであっても、アバターオブジェクト610の衣装を、ゲームの進行度合いに応じた衣装とするようにしてもよい。この場合、アバターオブジェクト610の衣装データは、各ユーザ端末100側において予め複数種類記憶されているようにしてもよい。なお、アバターオブジェクト610の表示態様を異ならせる対象は、衣装に限らず、髪型、肌の色、化粧の程度等であってもよい。これにより、ゲーム進行情報を出力するゲームプレイ端末300側の処理負担を増大させることなく、アバターオブジェクト610のバリエーションを増やすことができるため、ユーザを惹きつけることが可能となる。
【0309】
これに替えてあるいは加えて、アバターオブジェクト610の表示態様は、ゲーム中においてユーザによる課金に応じて、他のユーザのユーザ端末において表示される表示態様と異ならせることができるようにしてもよい。また、アバターオブジェクト610の表示態様は、ゲームの結果に応じて更新されるユーザのランキングに応じて異なるようにしてもよい。
【0310】
(8) 上記実施形態においては、音声データ、モーションデータおよび仮想空間制御データ各々の再生が第2タイミングから開始された後は、システム時間に基づいて当該再生が継続される(つまり、再生開始後はシステム時間により補完される)。しかし、当該再生の継続は、システム時間に基づくものに限らず、記憶されているデータ自体を単に再生することにより行うようにしてもよい。
【0311】
(9) 上記実施形態においては、音声データ、モーションデータおよび仮想空間制御データは、ライブ配信(リアルタイム配信)される。しかし、当該データは、予めサーバ200に記憶し、ユーザによる視聴操作に応じて当該ユーザのユーザ端末100に配信するようにしてもよい。
【0312】
(10) 上記実施形態においては、仮想空間制御データは、仮想空間600Bに配置された各種オブジェクトを動作させるためのモーションデータである。しかし、仮想空間制御データは、当該モーションデータ以外に、仮想空間600B内の効果音などの音声データや、仮想空間600Bに配置された仮想カメラ620Bの位置、傾きを制御するためのカメラ制御データを含むものであってもよい。
【0313】
<付記>
以上の各実施形態で説明した事項を、以下に付記する。
【0314】
(付記1):
本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、および表示部を備える端末装置(ユーザ端末100)において実行されるゲームプログラムであって、前記プロセッサに、演者の動きに応じてリアルタイムに動作するキャラクタを含む仮想空間の映像を表示するためのデータであってライブ配信されるデータ(ゲーム進行情報)を受信するステップと、受信したデータに基づいて前記仮想空間(600B)の映像を表示するステップとを実行させ、前記データは、ライブ配信を構成する第1のパートの終了に対応する第1データ(パート終了情報、場面終了情報)と、前記第1のパートに続く第2のパートの開始に対応する第2データ(パート開始情報、場面開始情報)とを含み、前記表示するステップは、前記第1データに基づいて前記第1のパートを終了するときに当該第1のパートの仮想空間の映像から予め定められている特定映像(転換画面)に切り替えて表示し、前記特定映像表示中において前記第2データを受信したときには、前記特定映像を表示していた表示時間にかかわらず、当該特定映像から前記第2のパートの仮想空間の映像に切り替えて表示する(
図28、
図29(A)参照)。
【0315】
(付記2):
(付記1)において、前記第2データは、前記第1データを配信した後の所定契機(演者の操作)成立時に配信されるデータであり、前記表示するステップは、前記表示時間が前記第1データ配信から前記第2データ配信までに要した時間に達していないときでも、前記特定映像を表示しているときに前記第2データを受信したときには前記特定映像から前記第2のパートの仮想空間の映像に切り替えて表示する(
図29(A)参照)。
【0316】
(付記3):
(付記1)または(付記2)において、前記表示するステップは、前記データがライブ配信されてから当該データに基づいて前記仮想空間の映像を表示するまでに特定時間以上を要する状況であるか否かを判定し、当該特定時間以上を要する状況である場合には前記特定映像に切り替えて表示した後、当該特定映像表示中に受信したデータに基づいて前記仮想空間の映像に切り替えて表示する(
図29(B)参照)。
【0317】
(付記4):
(付記3)において、前記特定時間は、前記第1データ配信から当該第2データ配信までに要する時間に応じて予め定められている時間(平均的な時間より短い時間)である。
【0318】
(付記5):
(付記1)~(付記4)のいずれかにおいて、前記データは、演者が入力した音声およびモーションに応じた音声データおよびモーションデータを含み(
図31参照)、前記表示するステップは、受信したデータのうち音声データの再生に合わせて、当該音声データを基準にして当該音声データに対応するモーションデータを再生して、前記仮想空間内において動作するキャラクタを表示し、前記第1のパートの終了を特定するための情報、および、前記第2のパートの開始を特定するための情報は、前記データのうちの前記音声データに含まれる。
【0319】
(付記6):
(付記1)~(付記5)のいずれかにおいて、前記ライブ配信を構成するパートには、前記端末装置を所有するユーザが参加可能となるゲームが行われる特定パート(ライブゲームパート)を含み、前記表示するステップは、前記特定パートの途中から前記ライブ配信の視聴を開始するときには、受信したデータに基づいて当該特定パートの前記仮想空間の映像を表示するとともに、所定タイミングまで待機を促すための待機情報を表示する(
図30参照)。
【0320】
(付記7):
(付記6)において、前記表示するステップは、前記特定パートの途中から前記ライブ配信の視聴を開始するタイミングが当該特定パートのうちの特定期間(参加不可能期間)中であるときには前記待機情報を表示しない一方、非特定期間(参加可能期間)中であるときには前記待機情報を表示する(
図30(D)および(E)参照)。
【0321】
(付記8):
(付記7)において、前記特定期間は、前記ゲームに参加するとユーザが不利となり得るとして予め定められている期間である。
【0322】
(付記9):
(付記6)~(付記8)のいずれかにおいて、前記表示するステップは、前記特定パートの途中から前記ライブ配信の視聴を開始するときには、前記特定映像を表示した後、受信したデータに基づいて前記仮想空間の映像に切り替えて表示する(
図30(C)参照)。
【0323】
(付記10):
(付記1)~(付記9)のいずれかにおいて、前記特定映像は、前記表示部の全表示領域を用いて表示される映像である(
図28(C)参照)。
【0324】
(付記11):
(付記1)~(付記10)のいずれかにおいて、前記特定映像は、終了する前記第1のパートの種類または当該特定映像表示後に開始する前記第2のパートの種類に応じた映像を含む。
【0325】
(付記12):
一実施形態のある局面によれば、プロセッサ、メモリ、および表示部を備える端末装置(ユーザ端末100)において実行されるゲーム方法であって、前記端末装置が、演者の動きに応じてリアルタイムに動作するキャラクタを含む仮想空間の映像を表示するためのデータであってライブ配信されるデータ(ゲーム進行情報)を受信するステップと、受信したデータに基づいて前記仮想空間(600B)の映像を表示するステップとを備え、前記データは、ライブ配信を構成する第1のパートの終了に対応する第1データ(パート終了情報、場面終了情報)と、前記第1のパートに続く第2のパートの開始に対応する第2データ(パート開始情報、場面開始情報)とを含み、前記表示するステップは、前記第1データに基づいて前記第1のパートを終了するときに当該第1のパートの仮想空間の映像から予め定められている特定映像(転換画面)に切り替えて表示し、前記特定映像表示中において前記第2データを受信したときには、前記特定映像を表示していた表示時間にかかわらず、当該特定映像から前記第2のパートの仮想空間の映像に切り替えて表示する(
図28、
図29(A)参照)。
【0326】
(付記13):
一実施形態のある局面によれば、端末装置(ユーザ端末100)であって、ゲームプログラムを記憶する記憶部と、前記ゲームプログラムを実行することにより、前記端末装置の動作を制御する制御部とを備え、前記制御部は、演者の動きに応じてリアルタイムに動作するキャラクタを含む仮想空間の映像を表示するためのデータであってライブ配信されるデータ(ゲーム進行情報)を受信するステップと、受信したデータに基づいて前記仮想空間(600B)の映像を表示するステップとを備え、前記データは、ライブ配信を構成する第1のパートの終了に対応する第1データ(パート終了情報、場面終了情報)と、前記第1のパートに続く第2のパートの開始に対応する第2データ(パート開始情報、場面開始情報)とを含み、前記表示するステップは、前記第1データに基づいて前記第1のパートを終了するときに当該第1のパートの仮想空間の映像から予め定められている特定映像(転換画面)に切り替えて表示し、前記特定映像表示中において前記第2データを受信したときには、前記特定映像を表示していた表示時間にかかわらず、当該特定映像から前記第2のパートの仮想空間の映像に切り替えて表示する(
図28、
図29(A)参照)。
【0327】
〔ソフトウェアによる実現例〕
ユーザ端末100、サーバ200、ゲームプレイ端末300(HMDセット1000)、および配信端末400の制御ブロック(特に制御部110、210、310、410)は、集積回路(ICチップ)等に形成された論理回路(ハードウェア)によって実現してもよいし、ソフトウェアによって実現してもよい。
【0328】
後者の場合、ユーザ端末100、サーバ200、ゲームプレイ端末300(HMDセット1000)、および配信端末400は、各機能を実現するソフトウェアであるプログラムの命令を実行するコンピュータを備えている。このコンピュータは、例えば1つ以上のプロセッサを備えていると共に、上記プログラムを記憶したコンピュータ読み取り可能な記録媒体を備えている。そして、上記コンピュータにおいて、上記プロセッサが上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記プロセッサとしては、例えばCPU(Central Processing Unit)を用いることができる。上記記録媒体としては、「一時的でない有形の媒体」、例えば、ROM(Read Only Memory)等の他、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムを展開するRAM(Random Access Memory)などをさらに備えていてもよい。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
【0329】
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
【符号の説明】
【0330】
1 システム、2 ネットワーク、3、3A、3B ユーザ(第1ユーザ)、4 プレイヤ(演者)、10,20,30,40 プロセッサ、11,21,31,41 メモリ、12,22,32,42 ストレージ、13,23,33,43 通信IF、14,24,34,44 入出力IF、15,45 タッチスクリーン、17 カメラ、18 測距センサ、51 モニタ、52 注視センサ、53 第1カメラ、54 第2カメラ、55 マイク、56 スピーカ、100,100A,100B,100C ユーザ端末(コンピュータ、第1コンピュータ、第1情報処理装置)、110,210,310,410 制御部(第1制御部、第2制御部)、111,311,413 操作受付部、112,312,412 表示制御部、113,313 UI制御部、114,314 アニメーション生成部、115,315 ゲーム進行部、116,316 仮想空間制御部、117 動画再生部、120,220,320,420 記憶部(第1記憶部、第2記憶部)、131,231,331 ゲームプログラム(プログラム、第1プログラム)、132,232,332 ゲーム情報、133,233,333 ユーザ情報、151,451 入力部、152,452 表示部(ディスプレイ)、200 サーバ、211 通信仲介部、212 ログ生成部、213 リスト生成部、234,421 ユーザリスト、300 ゲームプレイ端末(外部装置、第2外部装置)、317 反応処理部、400 配信端末(外部、第1外部装置、コンピュータ、第2情報処理装置)、411 通信制御部、414 音声受付部、415 モーション特定部、416 動作指図データ生成部、422 モーションリスト、423 配信プログラム(プログラム、第2プログラム)、540,1020,1021 コントローラ、500 HMD、510 HMDセンサ、520 モーションセンサ、530 ディスプレイ、600A、600B 仮想空間、610 アバターオブジェクト(キャラクタ)、620A,620B 仮想カメラ、631,632,633,634 オブジェクト、640A,640B 視界領域、650,660 視界画像、671 敵オブジェクト、672,673 障害物オブジェクト、674 演出オブジェクト、691,692 発話、701,702,703A,70B,704A,704B,705,706,711,711A,711B,711C,711D,722,723,745,745A,745B,745C,752,762,763,930,2011、2022、2031、2032、2033、2034、2037、2038、2051、2063、2072、2073、2075 UI画像(メッセージUI、UI)、721 ダウンロード画面、731 ユーザリスト画面(リスト)、732,732A,732B,732C,742,742A,742B,742C レコード画像、733,733A,733B,733C ユーザ名、734,734A,734B,734C タグ情報、735,735A,735B,735C アイコン、741 モーションリスト画面(選択肢)、743,743A,743B,743C モーション名、744,744A,744B,744C,753 モーション画像、751 配信画面、761 配信完了画面、810A,810B モーション動画、820A,820B 発話音声、910A,910B 動画、920A,920B 音声、1000 HMDセット、1010 物体、1030 記憶媒体