JP2022112769A

JP2022112769A - プログラム、方法、および情報端末装置

Info

Publication number: JP2022112769A
Application number: JP2021008697A
Authority: JP
Inventors: 功淳馬場; Naruatsu Baba; 潤哉福重; Junya Fukushige
Original assignee: Colopl Inc
Current assignee: Colopl Inc
Priority date: 2021-01-22
Filing date: 2021-01-22
Publication date: 2022-08-03

Abstract

【課題】好趣を向上させることができる、プログラム、方法、および情報端末装置を提供することである。【解決手段】キャラクタが配置されている仮想空間を表示するための表示用データを受信し、仮想空間内において視点を移動させるための態様が異なる複数種類の視聴モードのうちのいずれかを特定し、表示用データに基づく仮想空間内の画像のうち、特定するステップにより特定されている視聴モードに応じた態様で移動する視点からの画像を前記表示部に表示する。複数種類の視聴モードは、ユーザからの入力部に対する入力態様に応じて視点を移動可能となる視聴モードとして、キャラクタが配置され得る所定の範囲内への視点の移動を規制し得る第１視聴モードと、キャラクタが配置され得る所定の範囲内への視点の移動を許容するが所定の範囲内に視点を移動させたときにはキャラクタを非表示とし得る第２視聴モードとを含む。【選択図】図３０

Description

本発明は、プログラム、方法、および情報端末装置に関する。

特許文献１には、ライブ動画を視聴端末において表示するための動画データを当該視聴端末に配信する情報処理システムが記載されている。当該情報処理システムにおいては、コンテンツサーバから配信された動画データにより特定される動画が、視聴端末に表示される。

特開２０１２－１２００９８号公報

しかし、特許文献１のシステムでは、動画の表示モードや視点の制御方法などを変更することができない。このため、当該システムでは好趣に欠けるという問題があった。

本発明は、かかる実情に鑑み考え出されたものであり、その目的は、好趣を向上させることができる、プログラム、方法、および情報端末装置を提供することである。

本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、入力部、および表示部を備える情報端末装置において実行されるプログラムが提供される。プログラムは、プロセッサに、キャラクタが配置されている仮想空間を表示するための表示用データを受信するステップと、仮想空間内において視点を移動させるための態様が異なる複数種類の視聴モードのうちのいずれかを特定するステップと、表示用データに基づく仮想空間内の画像のうち、特定するステップにより特定されている視聴モードに応じた態様で移動する視点からの画像を前記表示部に表示するステップとを実行させ、複数種類の視聴モードは、ユーザからの入力部に対する入力態様に応じて視点を移動可能となる視聴モードとして、キャラクタが配置され得る所定の範囲内への視点の移動を規制し得る第１視聴モードと、キャラクタが配置され得る所定の範囲内への視点の移動を許容するが所定の範囲内に視点を移動させたときにはキャラクタを非表示とし得る第２視聴モードとを含む。

本発明によれば、好趣を向上させることができる。

ある実施の形態に従うシステムの概要の一例を示す図である。ある実施の形態に従うユーザ端末のハードウェア構成の一例を示すブロック図である。ある実施の形態に従うサーバのハードウェア構成の一例を示すブロック図である。ある実施の形態に従うゲームプレイ端末のハードウェア構成の一例を示すブロック図である。ある実施の形態に従う配信端末のハードウェア構成の一例を示すブロック図である。ある実施の形態に従うユーザ端末、サーバ、ＨＭＤセットの機能的構成の一例を示すブロック図である。ある実施の形態に従う配信端末の機能的構成の一例を示すブロック図である。ある実施の形態に従うユーザ端末およびゲームプレイ端末において実行される処理の一部を表すフローチャートである。ある実施の形態に従う、プレイヤに提供される仮想空間、および、プレイヤが視認する視界画像の一例を示す図である。ある実施の形態に従う、ユーザ端末のユーザに提供される仮想空間、および、該ユーザが視認する視界画像の一例を示す図である。ユーザ端末のユーザが視認する視界画像の他の例を示す図である。ユーザ端末のユーザが視認する視界画像のさらに別の例を示す図である。ある実施の形態に従うゲームプレイ端末において実行される処理の一部を表すフローチャートである。ある実施の形態に従うユーザ端末において実行される処理の一部を表すフローチャートである。ある実施の形態に従うサーバにおいて実行される処理の一部を表すフローチャートである。ある実施の形態に従う、ゲームに参加したユーザのリストの一具体例を示す図である。ある実施の形態に従う配信端末において実行される処理の一部を表すフローチャートである。ある実施の形態に従う配信端末に表示される画面の一具体例を示す図である。ある実施の形態に従う配信端末に表示される画面の他の具体例を示す図である。ある実施の形態に従う、プレイヤによる音声入力の一具体例を示す図である。ある実施の形態に従う配信端末に表示される画面のさらなる別の具体例と、動作指図データの配信の概要とを示す図である。ある実施の形態に従う、プレイヤによる音声入力の他の具体例を示す図である。ある実施の形態に従う配信端末に表示される画面のさらなる別の具体例と、動作指図データの配信の概要とを示す図である。ある実施形態に従うゲームプレイ端末からユーザ端末へのゲーム進行情報の送信の概要を示す図である。ある実施の形態に従うユーザ端末において実行される処理の一部を表すフローチャートである。動画再生の一具体例を示す図である。動画再生の他の具体例を示す図である。（Ａ）はジャンケンゲームの進行に際してゲームプレイ端末側において規定される仮想空間を模式的に説明するための図であり、（Ｂ）はユーザ端末側において規定され、取得画像に重畳させる拡張現実用の仮想空間を模式的に説明するための図である。モード切替え時の処理の流れの一例を示すフローチャートである。モード切替え後の処理の流れの一例を示すフローチャートである。通常モード中における所定範囲の一例を説明するための図である。ＡＲモード中における所定範囲の一例を説明するための図である。通常モード移行用アイコンへの入力操作が受け付けられた後における表示例を示す図である。ＴＶモード移行用アイコンへの入力操作が受け付けられた後における表示例を示す図である。ＡＲモード移行用アイコンへの入力操作が受け付けられた後における表示例を示す図である。ライブ配信映像の一例を示す図である。

本開示に係るシステムは、複数のユーザにゲームを提供するためのシステムである。以下、該システムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。

＜システム１の動作概要＞
図１は、本実施形態に係るシステム１の概要を示す図である。システム１は、複数のユーザ端末１００（コンピュータ）と、サーバ２００と、ゲームプレイ端末３００（外部装置、第２外部装置）と、配信端末４００（外部、第１外部装置）とを含む。なお、図１では、複数のユーザ端末１００の一例として、ユーザ端末１００Ａ～１００Ｃ、換言すれば、３台のユーザ端末１００を記載しているが、ユーザ端末１００の台数は図示の例に限定されない。また、本実施形態では、ユーザ端末１００Ａ～Ｃを区別する必要が無い場合、「ユーザ端末１００」と記載する。ユーザ端末１００、ゲームプレイ端末３００、および配信端末４００は、サーバ２００とネットワーク２を介して接続する。ネットワーク２は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂３Ｇ、４Ｇ移動通信システム、ＬＴＥ（Long Term Evolution）、および所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク（例えばWi-Fi（登録商標））等が挙げられる。

（ゲームの概要）
本実施形態では、システム１によって提供されるゲーム（以下、本ゲーム）の一例として、ゲームプレイ端末３００のユーザが主としてプレイするゲームを説明する。以下、ゲームプレイ端末３００のユーザを、「プレイヤ」と称する。プレイヤ（演者）は、一例として、本ゲームに登場するキャラクタを操作することにより、ゲームを進行させる。また、本ゲームにおいて、ユーザ端末１００のユーザは、プレイヤによるゲームの進行を支援する役割を担う。本ゲームの詳細については後述する。なお、システム１によって提供されるゲームは、複数のユーザが参加するゲームであればよく、この例に限定されない。

（ゲームプレイ端末３００）
ゲームプレイ端末３００は、プレイヤによる入力操作に応じてゲームを進行させる。また、ゲームプレイ端末３００は、プレイヤのゲームプレイにより生成された情報（以下、ゲーム進行情報）を、順次、サーバ２００にリアルタイムで配信する。

（サーバ２００）
サーバ２００は、ゲームプレイ端末３００からリアルタイムに受信したゲーム進行情報（第２データ）を、ユーザ端末１００に送信する。また、サーバ２００は、ユーザ端末１００、ゲームプレイ端末３００、および配信端末４００の間の各種情報の送受信を仲介する。

（配信端末４００）
配信端末４００は、配信端末４００のユーザによる入力操作に応じて、動作指図データ（第１データ）を生成し、サーバ２００を介してユーザ端末１００へ動作指図データを配信する。動作指図データとは、ユーザ端末１００において動画を再生するためのデータであり、具体的には、動画に登場するキャラクタを動作させるためのデータである。

本実施形態では、一例として、配信端末４００のユーザは、本ゲームのプレイヤである。また、一例として、ユーザ端末１００にて動作指図データに基づいて再生される動画は、プレイヤがゲームで操作したキャラクタが動作する動画である。「動作」とは、キャラクタの身体の少なくとも一部を動かすことであり、発話も含む。このため、本実施形態に係る動作指図データは、例えば、キャラクタに発話させるための音声データと、キャラクタの身体を動かすためのモーションデータとを含む。

動作指図データは、一例として、本ゲームの終了後にユーザ端末１００へ送信される。動作指図データ、および、該動作指図データに基づいて再生される動画の詳細については後述する。

（ユーザ端末１００）
ユーザ端末１００は、ゲーム進行情報をリアルタイムに受信し、該情報を用いてゲーム画面を生成して表示する。換言すれば、ユーザ端末１００は、リアルタイムレンダリングにより、プレイヤがプレイしているゲームのゲーム画面を再生する。これにより、ユーザ端末１００のユーザは、プレイヤがゲームをプレイしながら視認しているゲーム画面と同一のゲーム画面を、プレイヤとほぼ同じタイミングで視認することができる。

また、ユーザ端末１００は、ユーザによる入力操作に応じて、プレイヤによるゲームの進行を支援するための情報を生成し、該情報を、サーバ２００を介してゲームプレイ端末３００へ送信する。該情報の詳細については後述する。

また、ユーザ端末１００は、配信端末４００から動作指図データを受信し、該動作指図データを用いて動画（映像）を生成して再生する。換言すれば、ユーザ端末１００は、動作指図データをレンダリングして再生する。

＜システム１のハードウェア構成＞
図２は、ユーザ端末１００のハードウェア構成を示す図である。図３は、サーバ２００のハードウェア構成を示す図である。図４は、ゲームプレイ端末３００のハードウェア構成を示す図である。図５は、配信端末４００のハードウェア構成を示す図である。

（ユーザ端末１００）
本実施形態では、一例として、ユーザ端末１００がスマートフォンとして実現される例を説明するが、ユーザ端末１００はスマートフォンに限定されない。例えば、ユーザ端末１００はフィーチャーフォン、タブレット型コンピュータ、ラップトップ型コンピュータ（いわゆる、ノートパソコン）、または、デスクトップ型コンピュータなどとして実現されてもよい。また、ユーザ端末１００は、ゲームプレイに適したゲーム装置であってもよい。

ユーザ端末１００は図２に示すように、プロセッサ１０と、メモリ１１と、ストレージ１２と、通信インターフェース（ＩＦ）１３と、入出力ＩＦ１４と、タッチスクリーン１５（表示部）と、カメラ１７と、測距センサ１８とを備える。ユーザ端末１００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。なお、ユーザ端末１００は、タッチスクリーン１５に代えて、または、加えて、ユーザ端末１００本体とは別に構成されたディスプレイ（表示部）を接続可能な入出力ＩＦ１４を備えていてもよい。

また、図２に示すように、ユーザ端末１００は、１つ以上のコントローラ１０２０と通信可能に構成されることとしてもよい。コントローラ１０２０は、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の通信規格に従って、ユーザ端末１００と通信を確立する。コントローラ１０２０は、１つ以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末１００へ送信する。また、コントローラ１０２０は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末１００へ送信する。

なお、ユーザ端末１００がカメラ１７および測距センサ１８を備えることに代えて、または、加えて、コントローラ１０２０がカメラ１７および測距センサ１８を有していてもよい。

ユーザ端末１００は、例えばゲーム開始時に、コントローラ１０２０を使用するユーザに、該ユーザの名前またはログインＩＤ等のユーザ識別情報を、該コントローラ１０２０を介して入力させることが望ましい。これにより、ユーザ端末１００は、コントローラ１０２０とユーザとを紐付けることが可能となり、受信した出力値の送信元（コントローラ１０２０）に基づいて、該出力値がどのユーザのものであるかを特定することができる。

ユーザ端末１００が複数のコントローラ１０２０と通信する場合、各コントローラ１０２０を各ユーザが把持することで、ネットワーク２を介してサーバ２００などの他の装置と通信せずに、該１台のユーザ端末１００でマルチプレイを実現することができる。また、各ユーザ端末１００が無線ＬＡＮ（Local Area Network）規格等の無線規格により互いに通信接続する（サーバ２００を介さずに通信接続する）ことで、複数台のユーザ端末１００によりローカルでマルチプレイを実現することもできる。１台のユーザ端末１００によりローカルで上述のマルチプレイを実現する場合、ユーザ端末１００は、さらに、サーバ２００が備える後述する種々の機能の少なくとも一部を備えていてもよい。また、複数のユーザ端末１００によりローカルで上述のマルチプレイを実現する場合、複数のユーザ端末１００は、サーバ２００が備える後述する種々の機能を分散して備えていてもよい。

なお、ローカルで上述のマルチプレイを実現する場合であっても、ユーザ端末１００はサーバ２００と通信を行ってもよい。例えば、あるゲームにおける成績または勝敗等のプレイ結果を示す情報と、ユーザ識別情報とを対応付けてサーバ２００に送信してもよい。

また、コントローラ１０２０は、ユーザ端末１００に着脱可能な構成であるとしてもよい。この場合、ユーザ端末１００の筐体における少なくともいずれかの面に、コントローラ１０２０との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末１００とコントローラ１０２０とが結合している場合は、ユーザ端末１００とコントローラ１０２０とは、有線を介して信号を送受信する。

図２に示すように、ユーザ端末１００は、外部のメモリカード等の記憶媒体１０３０の装着を、入出力ＩＦ１４を介して受け付けてもよい。これにより、ユーザ端末１００は、記憶媒体１０３０に記録されるプログラム及びデータを読み込むことができる。記憶媒体１０３０に記録されるプログラムは、例えばゲームプログラムである。

ユーザ端末１００は、サーバ２００等の外部の装置と通信することにより取得したゲームプログラムをユーザ端末１００のメモリ１１に記憶してもよいし、記憶媒体１０３０から読み込むことにより取得したゲームプログラムをメモリ１１に記憶してもよい。

以上で説明したとおり、ユーザ端末１００は、該ユーザ端末１００に対して情報を入力する機構の一例として、通信ＩＦ１３、入出力ＩＦ１４、タッチスクリーン１５、カメラ１７、および、測距センサ１８を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。

例えば、操作部が、カメラ１７および測距センサ１８の少なくともいずれか一方で構成される場合、該操作部が、ユーザ端末１００の近傍の物体１０１０を検出し、当該物体の検出結果から入力操作を特定する。一例として、物体１０１０としてのユーザの手、予め定められた形状のマーカーなどが検出され、検出結果として得られた物体１０１０の色、形状、動き、または、種類などに基づいて入力操作が特定される。より具体的には、ユーザ端末１００は、カメラ１７の撮影画像からユーザの手が検出された場合、該撮影画像に基づき検出されるジェスチャ（ユーザの手の一連の動き）を、ユーザの入力操作として特定し、受け付ける。なお、撮影画像は静止画であっても動画であってもよい。

あるいは、操作部がタッチスクリーン１５で構成される場合、ユーザ端末１００は、タッチスクリーン１５の入力部１５１に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信ＩＦ１３で構成される場合、ユーザ端末１００は、コントローラ１０２０から送信される信号（例えば、出力値）をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力ＩＦ１４で構成される場合、該入出力ＩＦ１４と接続されるコントローラ１０２０とは異なる入力装置（図示せず）から出力される信号をユーザの入力操作として特定し、受け付ける。

（サーバ２００）
サーバ２００は、一例として、ワークステーションまたはパーソナルコンピュータなどの汎用コンピュータであってよい。サーバ２００は、プロセッサ２０と、メモリ２１と、ストレージ２２と、通信ＩＦ２３と、入出力ＩＦ２４とを備える。サーバ２００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。

（ゲームプレイ端末３００）
ゲームプレイ端末３００は、一例として、パーソナルコンピュータなどの汎用コンピュータであってよい。ゲームプレイ端末３００は、プロセッサ３０と、メモリ３１と、ストレージ３２と、通信ＩＦ３３と、入出力ＩＦ３４とを備える。ゲームプレイ端末３００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。

図４に示すように、本実施形態に係るゲームプレイ端末３００は、一例として、ＨＭＤ（Head Mounted Display）セット１０００に含まれる。つまり、ＨＭＤセット１０００が、システム１に含まれていると表現することができ、また、プレイヤは、ＨＭＤセット１０００を用いてゲームをプレイすると表現することもできる。なお、プレイヤがゲームをプレイするための装置は、ＨＭＤセット１０００に限定されない。一例として、該装置は、プレイヤにゲームを仮想体験させることが可能な装置であればよい。また、該装置は、スマートフォン、フィーチャーフォン、タブレット型コンピュータ、ラップトップ型コンピュータ（いわゆる、ノートパソコン）、または、デスクトップ型コンピュータなどとして実現されてもよい。また、該装置は、ゲームプレイに適したゲーム装置であってもよい。

ＨＭＤセット１０００は、ゲームプレイ端末３００の他、ＨＭＤ５００、ＨＭＤセンサ５１０、モーションセンサ５２０、ディスプレイ５３０、コントローラ５４０を備える。ＨＭＤ５００は、モニタ５１と、注視センサ５２と、第１カメラ５３と、第２カメラ５４と、マイク５５と、スピーカ５６とを含む。コントローラ５４０は、モーションセンサ５２０を含み得る。

ＨＭＤ５００は、プレイヤの頭部に装着され、動作中に仮想空間をプレイヤに提供し得る。より具体的には、ＨＭＤ５００は、右目用の画像および左目用の画像をモニタ５１にそれぞれ表示する。プレイヤの各目がそれぞれの画像を視認すると、プレイヤは、両目の視差に基づき当該画像を３次元画像として認識し得る。ＨＭＤ５００は、モニタを備える所謂ヘッドマウントディスプレイと、スマートフォンその他のモニタを有する端末を装着可能なヘッドマウント機器のいずれをも含み得る。

モニタ５１は、例えば、非透過型の表示装置として実現される。ある局面において、モニタ５１は、プレイヤの両目の前方に位置するようにＨＭＤ５００の本体に配置されている。したがって、プレイヤは、モニタ５１に表示される３次元画像を視認すると、仮想空間に没入することができる。ある局面において、仮想空間は、例えば、背景、プレイヤが操作可能なオブジェクト、プレイヤが選択可能なメニューの画像を含む。ある局面において、モニタ５１は、所謂スマートフォンその他の情報表示端末が備える液晶モニタまたは有機ＥＬ（Electro Luminescence）モニタとして実現され得る。

別の局面において、モニタ５１は、透過型の表示装置として実現され得る。この場合、ＨＭＤ５００は、図１に示されるようにプレイヤの目を覆う密閉型ではなく、メガネ型のような開放型であり得る。透過型のモニタ５１は、その透過率を調整することにより、一時的に非透過型の表示装置として構成可能であってもよい。モニタ５１は、仮想空間を構成する画像の一部と、現実空間とを同時に表示する構成を含んでいてもよい。例えば、モニタ５１は、ＨＭＤ５００に搭載されたカメラで撮影した現実空間の画像を表示してもよいし、一部の透過率を高く設定することにより現実空間を視認可能にしてもよい。

ある局面において、モニタ５１は、右目用の画像を表示するためのサブモニタと、左目用の画像を表示するためのサブモニタとを含み得る。別の局面において、モニタ５１は、右目用の画像と左目用の画像とを一体として表示する構成であってもよい。この場合、モニタ５１は、高速シャッタを含む。高速シャッタは、画像がいずれか一方の目にのみ認識されるように、右目用の画像と左目用の画像とを交互に表示可能に作動する。

ある局面において、ＨＭＤ５００は、図示せぬ複数の光源を含む。各光源は例えば、赤外線を発するＬＥＤ（Light Emitting Diode）により実現される。ＨＭＤセンサ５１０は、ＨＭＤ５００の動きを検出するためのポジショントラッキング機能を有する。より具体的には、ＨＭＤセンサ５１０は、ＨＭＤ５００が発する複数の赤外線を読み取り、現実空間内におけるＨＭＤ５００の位置および傾きを検出する。

別の局面において、ＨＭＤセンサ５１０は、カメラにより実現されてもよい。この場合、ＨＭＤセンサ５１０は、カメラから出力されるＨＭＤ５００の画像情報を用いて、画像解析処理を実行することにより、ＨＭＤ５００の位置および傾きを検出することができる。

別の局面において、ＨＭＤ５００は、位置検出器として、ＨＭＤセンサ５１０の代わりに、あるいはＨＭＤセンサ５１０に加えてセンサ（不図示）を備えてもよい。ＨＭＤ５００は、該センサを用いて、ＨＭＤ５００自身の位置および傾きを検出し得る。例えば、該センサが角速度センサ、地磁気センサ、あるいは加速度センサである場合、ＨＭＤ５００は、ＨＭＤセンサ５１０の代わりに、これらの各センサのいずれかを用いて、自身の位置および傾きを検出し得る。一例として、ＨＭＤ５００に備えられたセンサが角速度センサである場合、角速度センサは、現実空間におけるＨＭＤ５００の３軸周りの角速度を経時的に検出する。ＨＭＤ５００は、各角速度に基づいて、ＨＭＤ５００の３軸周りの角度の時間的変化を算出し、さらに、角度の時間的変化に基づいて、ＨＭＤ５００の傾きを算出する。

注視センサ５２は、プレイヤの右目および左目の視線が向けられる方向を検出する。つまり、注視センサ５２は、プレイヤの視線を検出する。視線の方向の検出は、例えば、公知のアイトラッキング機能によって実現される。注視センサ５２は、当該アイトラッキング機能を有するセンサにより実現される。ある局面において、注視センサ５２は、右目用のセンサおよび左目用のセンサを含むことが好ましい。注視センサ５２は、例えば、プレイヤの右目および左目に赤外光を照射するとともに、照射光に対する角膜および虹彩からの反射光を受けることにより各眼球の回転角を検出するセンサであってもよい。注視センサ５２は、検出した各回転角に基づいて、プレイヤの視線を検知することができる。

第１カメラ５３は、プレイヤの顔の下部を撮影する。より具体的には、第１カメラ５３は、プレイヤの鼻および口などを撮影する。第２カメラ５４は、プレイヤの目および眉などを撮影する。ＨＭＤ５００のプレイヤ側の筐体をＨＭＤ５００の内側、ＨＭＤ５００のプレイヤとは逆側の筐体をＨＭＤ５００の外側と定義する。ある局面において、第１カメラ５３は、ＨＭＤ５００の外側に配置され、第２カメラ５４は、ＨＭＤ５００の内側に配置され得る。第１カメラ５３および第２カメラ５４が生成した画像は、ゲームプレイ端末３００に入力される。別の局面において、第１カメラ５３と第２カメラ５４とを１台のカメラとして実現し、この１台のカメラでプレイヤの顔を撮影するようにしてもよい。

マイク５５は、プレイヤの発話を音声信号（電気信号）に変換してゲームプレイ端末３００に出力する。スピーカ５６は、音声信号を音声に変換してプレイヤに出力する。別の局面において、ＨＭＤ５００は、スピーカ５６に替えてイヤホンを含み得る。

コントローラ５４０は、有線または無線によりゲームプレイ端末３００に接続されている。コントローラ５４０は、プレイヤからゲームプレイ端末３００への命令の入力を受け付ける。ある局面において、コントローラ５４０は、プレイヤによって把持可能に構成される。別の局面において、コントローラ５４０は、プレイヤの身体あるいは衣類の一部に装着可能に構成される。さらに別の局面において、コントローラ５４０は、ゲームプレイ端末３００から送信される信号に基づいて、振動、音、光のうちの少なくともいずれかを出力するように構成されてもよい。さらに別の局面において、コントローラ５４０は、プレイヤから、仮想空間に配置されるオブジェクトの位置や動きを制御するための操作を受け付ける。

ある局面において、コントローラ５４０は、複数の光源を含む。各光源は例えば、赤外線を発するＬＥＤにより実現される。ＨＭＤセンサ５１０は、ポジショントラッキング機能を有する。この場合、ＨＭＤセンサ５１０は、コントローラ５４０が発する複数の赤外線を読み取り、現実空間内におけるコントローラ５４０の位置および傾きを検出する。別の局面において、ＨＭＤセンサ５１０は、カメラにより実現されてもよい。この場合、ＨＭＤセンサ５１０は、カメラから出力されるコントローラ５４０の画像情報を用いて、画像解析処理を実行することにより、コントローラ５４０の位置および傾きを検出することができる。

モーションセンサ５２０は、ある局面において、プレイヤの手に取り付けられて、プレイヤの手の動きを検出する。例えば、モーションセンサ５２０は、手の回転速度、回転数等を検出する。検出された信号は、ゲームプレイ端末３００に送られる。モーションセンサ５２０は、例えば、コントローラ５４０に設けられている。ある局面において、モーションセンサ５２０は、例えば、プレイヤに把持可能に構成されたコントローラ５４０に設けられている。別の局面において、現実空間における安全のため、コントローラ５４０は、手袋型のようにプレイヤの手に装着されることにより容易に飛んで行かないものに装着される。さらに別の局面において、プレイヤに装着されないセンサがプレイヤの手の動きを検出してもよい。例えば、プレイヤを撮影するカメラの信号が、プレイヤの動作を表わす信号として、ゲームプレイ端末３００に入力されてもよい。モーションセンサ５２０とゲームプレイ端末３００とは、一例として、無線により互いに接続される。無線の場合、通信形態は特に限られず、例えば、Ｂｌｕｅｔｏｏｔｈその他の公知の通信手法が用いられる。

ディスプレイ５３０は、モニタ５１に表示されている画像と同様の画像を表示する。これにより、ＨＭＤ５００を装着しているプレイヤ以外のユーザにもプレイヤと同様の画像を視聴させることができる。ディスプレイ５３０に表示される画像は、３次元画像である必要はなく、右目用の画像や左目用の画像であってもよい。ディスプレイ５３０としては、例えば、液晶ディスプレイや有機ＥＬモニタなどが挙げられる。

ゲームプレイ端末３００は、ＨＭＤ５００の各部、コントローラ５４０、およびモーションセンサ５２０から取得した各種情報に基づいて、プレイヤの操作対象となるキャラクタを動作させ、ゲームを進行させる。ここでの「動作」には、身体の各部を動かすこと、姿勢を変えること、顔の表情を変えること、移動、発話、仮想空間に配置されたオブジェクトに触れたり、動かしたりすること、キャラクタが把持する武器、道具などを使用することなどが含まれる。すなわち、本ゲームでは、プレイヤが身体の各部を動かすことにより、キャラクタもプレイヤと同様に身体の各部を動かす。また、本ゲームでは、プレイヤが発話した内容をキャラクタが発話する。換言すれば、本ゲームにおいて、キャラクタは、プレイヤの分身としてふるまうアバターオブジェクトである。一例として、キャラクタの動作の少なくとも一部が、プレイヤによるコントローラ５４０に対する入力により実行されてもよい。

本実施形態では、モーションセンサ５２０は、一例として、プレイヤの両手、プレイヤの両足、プレイヤの腰部、および、プレイヤの頭部に取り付けられる。プレイヤの両手に取り付けられるモーションセンサ５２０は、上述したとおり、コントローラ５４０に設けられていてもよい。また、プレイヤの頭部に取り付けられるモーションセンサ５２０は、ＨＭＤ５００に設けられていてもよい。モーションセンサ５２０は、さらに、ユーザの両肘や両膝に取り付けられてもよい。プレイヤに取り付けるモーションセンサ５２０の数を増やすことにより、プレイヤの動きをより正確にキャラクタに反映させることができる。
また、プレイヤは、モーションセンサ５２０を身体の各部に取り付けることに代えて、１以上のモーションセンサ５２０が取り付けられたスーツを着用してもよい。つまり、モーションキャプチャの方法は、モーションセンサ５２０を用いる例に限定されない。

（配信端末４００）
配信端末４００は、スマートフォン、ＰＤＡ（Personal Digital Assistant）、またはタブレット型コンピュータ等の携帯端末であってよい。また、配信端末４００は、デスクトップパソコン等の、いわゆる据え置き型の端末であってもよい。

配信端末４００は、図５に示すように、プロセッサ４０と、メモリ４１と、ストレージ４２と、通信ＩＦ４３と、入出力ＩＦ４４と、タッチスクリーン４５とを備える。なお、配信端末４００は、タッチスクリーン４５に代えて、または、加えて、配信端末４００本体とは別に構成されたディスプレイ（表示部）を接続可能な入出力ＩＦ４４を備えていてもよい。

コントローラ１０２１は、１つ以上のボタン、レバー、スティック、ホイール等の物理的な入力機構を有していてもよい。コントローラ１０２１は、配信端末４００の操作者（本実施形態ではプレイヤ）が、該入力機構に対して入力した入力操作に基づく出力値を配信端末４００へ送信する。また、コントローラ１０２１は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値を配信端末４００へ送信してもよい。上述の出力値は、通信ＩＦ４３を介して配信端末４００に受け付けられる。

配信端末４００は、カメラと、測距センサ（ともに不図示）とを備えていてもよい。配信端末４００が備えることに代えて、または、加えて、コントローラ１０２１がカメラと、測距センサとを有してしてもよい。

以上で説明したとおり、配信端末４００は、該配信端末４００に対して情報を入力する機構の一例として、通信ＩＦ４３、入出力ＩＦ４４、タッチスクリーン４５を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。

操作部がタッチスクリーン４５で構成されている場合、配信端末４００は、タッチスクリーン４５の入力部４５１に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信ＩＦ４３で構成される場合、配信端末４００は、コントローラ１０２１から送信される信号（例えば、出力値）をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力ＩＦ４４で構成される場合、配信端末４００は、該入出力ＩＦ４４と接続される入力装置（図示せず）から出力される信号をユーザの入力操作として特定し、受け付ける。

＜各装置のハードウェア構成要素＞
プロセッサ１０、２０、３０、４０はそれぞれ、ユーザ端末１００、サーバ２００、ゲームプレイ端末３００、配信端末４００の全体の動作を制御する。プロセッサ１０、２０、３０、４０は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、およびＧＰＵ（Graphics Processing Unit）を含む。プロセッサ１０、２０、３０、４０は、それぞれ、後述するストレージ１２、２２、３２、４２からプログラムを読み出す。そして、プロセッサ１０、２０、３０、４０は、それぞれ、読み出したプログラムを、後述するメモリ１１、２１、３１、４１に展開する。プロセッサ１０、２０、３０は、展開したプログラムを実行する。

メモリ１１、２１、３１、４１は主記憶装置である。メモリ１１、２１、３１、４１は、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）等の記憶装置で構成される。メモリ１１は、プロセッサ１０が後述するストレージ１２から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ１０に作業領域を提供する。メモリ１１は、プロセッサ１０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ２１は、プロセッサ２０が後述するストレージ２２から読み出した各種プログラムおよびデータを一時的に記憶することにより、プロセッサ２０に作業領域を提供する。メモリ２１は、プロセッサ２０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ３１は、プロセッサ３０が後述するストレージ３２から読み出した各種プログラムおよびデータを一時的に記憶することにより、プロセッサ３０に作業領域を提供する。メモリ３１は、プロセッサ３０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ４１は、プロセッサ４０が後述するストレージ４２から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ４０に作業領域を提供する。メモリ４１は、プロセッサ４０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。

本実施形態において、プロセッサ１０および３０が実行するプログラムは、本ゲームのゲームプログラムであってもよい。本実施形態において、プロセッサ４０が実行するプログラムは、動作指図データの配信を実現するための配信プログラムであってもよい。また、プロセッサ１０は、さらに、動画の再生を実現するための視聴プログラムを実行してもよい。

本実施形態において、プロセッサ２０が実行するプログラムは、上述のゲームプログラム、配信プログラム、視聴プログラムの少なくとも何れかであってもよい。プロセッサ２０は、ユーザ端末１００、ゲームプレイ端末３００、および配信端末４００の少なくとも何れかからの要求等に応じて、ゲームプログラム、配信プログラム、視聴プログラムの少なくとも何れかを実行する。なお、配信プログラムと視聴プログラムは、並行して実行されてもよい。

すなわち、ゲームプログラムは、ゲームをユーザ端末１００、サーバ２００、およびゲームプレイ端末３００の協働により実現するプログラムであってもよい。配信プログラムは、動作指図データの配信を、サーバ２００と配信端末４００との協働により実現するプログラムであってもよい。視聴プログラムは、動画の再生を、ユーザ端末１００とサーバ２００との協働により実現するプログラムであってもよい。

ストレージ１２、２２、３２、４２は補助記憶装置である。ストレージ１２、２２、３２、４２は、フラッシュメモリまたはＨＤＤ（Hard Disk Drive）等の記憶装置で構成される。ストレージ１２、３２には、例えば、ゲームに関する各種データが格納される。ストレージ４２には、動作指図データの配信に関する各種データが格納される。また、ストレージ１２には、動画の再生に関する各種データが格納される。ストレージ２２には、ゲーム、動作指図データの配信、および動画の再生それぞれに関する各種データのうち、少なくとも一部が格納されてもよい。

通信ＩＦ１３、２３、３３、４３は、それぞれ、ユーザ端末１００、サーバ２００、ゲームプレイ端末３００、配信端末４００における各種データの送受信を制御する。通信ＩＦ１３、２３、３３、４３は例えば、無線ＬＡＮ（Local Area Network）を介する通信、有線ＬＡＮ、無線ＬＡＮ、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。

入出力ＩＦ１４、２４、３４、４４は、それぞれ、ユーザ端末１００、サーバ２００、ゲームプレイ端末３００、配信端末４００がデータの入力を受け付けるため、また、データを出力するためのインターフェースである。入出力ＩＦ１４、２４、３４、４４は、ＵＳＢ（Universal Serial Bus）等を介してデータの入出力を行ってもよい。入出力ＩＦ１４、２４、３４、４４は、物理ボタン、カメラ、マイク、スピーカ、マウス、キーボード、ディスプレイ、スティック、レバーなどを含み得る。また、入出力ＩＦ１４、２４、３４、４４は、周辺機器との間でデータを送受信するための接続部を含み得る。

タッチスクリーン１５は、入力部１５１と表示部１５２（ディスプレイ）とを組み合わせた電子部品である。タッチスクリーン４５は、入力部４５１と表示部４５２とを組み合わせた電子部品である。入力部１５１および４５１は、一例として、タッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部１５２および４５２は、例えば液晶ディスプレイ、または有機ＥＬ（Electro-Luminescence）ディスプレイ等によって構成される。

入力部１５１および４５１は、入力面に対しユーザの操作（主にタッチ操作、スライド操作、スワイプ操作、ピンチイン／ピンチアウト操作、およびタップ操作等の物理的接触操作）が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部１５１および４５１は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。

図示していないが、ユーザ端末１００および配信端末４００は、それぞれ、ユーザ端末１００および配信端末４００の保持姿勢を特定するための１以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。

ユーザ端末１００および配信端末４００がセンサを備えている場合、プロセッサ１０および４０は、それぞれ、センサの出力からユーザ端末１００および配信端末４００の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ１０および４０は、それぞれ、ユーザ端末１００および配信端末４００が縦向きに保持されているときには、縦長の画像を表示部１５２および４５２に表示させる縦画面表示としてもよい。一方、ユーザ端末１００および配信端末４００が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ１０および４０は、それぞれ、ユーザ端末１００および配信端末４００の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。

＜システム１の機能的構成＞
図６は、システム１に含まれるユーザ端末１００、サーバ２００、およびＨＭＤセット１０００の機能的構成を示すブロック図である。図７は、図６に示す配信端末４００の機能的構成を示すブロック図である。

ユーザ端末１００は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末１００は、プロセッサ１０、メモリ１１、ストレージ１２、通信ＩＦ１３、入出力ＩＦ１４、およびタッチスクリーン１５等の協働によって、制御部１１０および記憶部１２０として機能する。

サーバ２００は、ユーザ端末１００、ＨＭＤセット１０００、および配信端末４００の間の各種情報の送受信を仲介する機能を有する。サーバ２００は、プロセッサ２０、メモリ２１、ストレージ２２、通信ＩＦ２３、および入出力ＩＦ２４等の協働によって、制御部２１０および記憶部２２０として機能する。

ＨＭＤセット１０００（ゲームプレイ端末３００）は、プレイヤの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能と、ゲーム進行情報を、サーバ２００を介してユーザ端末１００へリアルタイムに送信する機能を有する。ＨＭＤセット１０００は、ゲームプレイ端末３００のプロセッサ３０、メモリ３１、ストレージ３２、通信ＩＦ３３、入出力ＩＦ３４、並びに、ＨＭＤ５００、ＨＭＤセンサ５１０、モーションセンサ５２０、およびコントローラ５４０等の協働によって、制御部３１０および記憶部３２０として機能する。

配信端末４００は、動作指図データを生成して、該動作指図データを、サーバ２００を介してユーザ端末１００へ送信する機能を有する。配信端末４００は、プロセッサ４０、メモリ４１、ストレージ４２、通信ＩＦ４３、入出力ＩＦ４４、およびタッチスクリーン４５等の協働によって、制御部４１０および記憶部４２０として機能する。

（各装置の記憶部が格納するデータ）
記憶部１２０は、ゲームプログラム１３１（プログラム）、ゲーム情報１３２、および、ユーザ情報１３３を格納する。記憶部２２０は、ゲームプログラム２３１、ゲーム情報２３２、ユーザ情報２３３、および、ユーザリスト２３４を格納する。記憶部３２０は、ゲームプログラム３３１、ゲーム情報３３２、および、ユーザ情報３３３を格納する。記憶部４２０は、ユーザリスト４２１、モーションリスト４２２、配信プログラム４２３（プログラム、第２プログラム）を格納する。

ゲームプログラム１３１、２３１、３３１は、それぞれ、ユーザ端末１００、サーバ２００、ＨＭＤセット１０００が実行するゲームプログラムである。ゲームプログラム１３１、２３１、３３１に基づいて各装置が協働して動作することにより、本ゲームが実現される。なお、ゲームプログラム１３１および３３１は、記憶部２２０に格納され、ユーザ端末１００およびＨＭＤセット１０００にそれぞれダウンロードされる構成でもよい。なお、本実施形態では、ユーザ端末１００は、ゲームプログラム１３１に基づいて、配信端末４００から受信したデータをレンダリングし、動画を再生するものとする。換言すれば、ゲームプログラム１３１は、配信端末４００から配信された動画指図データを用いて、動画を再生するためのプログラムでもある。該動画を再生するためのプログラムは、ゲームプログラム１３１と異なってもよい。この場合、記憶部１２０は、ゲームプログラム１３１とは別に、該動画を再生するためのプログラムを格納する。

ゲーム情報１３２、２３２、３３２は、それぞれ、ユーザ端末１００、サーバ２００、ＨＭＤセット１０００がゲームプログラムを実行する際に参照するデータである。ユーザ情報１３３、２３３、３３３は、ユーザ端末１００のユーザのアカウントに関するデータである。ゲーム情報２３２は、各ユーザ端末１００のゲーム情報１３２、および、ＨＭＤセット１０００のゲーム情報３３２である。ユーザ情報２３３は、各ユーザ端末１００のユーザ情報１３３、および、ユーザ情報３３３に含まれる、プレイヤのユーザ情報である。ユーザ情報３３３は、各ユーザ端末１００のユーザ情報１３３、および、プレイヤのユーザ情報である。

ユーザリスト２３４およびユーザリスト４２１は、ゲームに参加したユーザのリストである。ユーザリスト２３４およびユーザリスト４２１は、プレイヤによる直近のゲームプレイにおいて参加したユーザのリストの他、該ゲームプレイ以前の各ゲームプレイにおいて参加したユーザのリストを含んでいてもよい。モーションリスト４２２は、予め作成されている複数のモーションデータのリストである。モーションリスト４２２は、例えば、各モーションを識別する情報（例えば、モーション名）のそれぞれに、モーションデータが対応付けられたリストである。配信プログラム４２３は、ユーザ端末１００にて動画を再生するための動作指図データの、ユーザ端末１００への配信を実現するためのプログラムである。

（サーバ２００の機能的構成）
制御部２１０は、記憶部２２０に格納されたゲームプログラム２３１を実行することにより、サーバ２００を統括的に制御する。例えば制御部２１０は、ユーザ端末１００、ＨＭＤセット１０００、および配信端末４００の間の各種情報の送受信を仲介する。

制御部２１０は、ゲームプログラム２３１の記述に応じて、通信仲介部２１１、ログ生成部２１２、リスト生成部２１３として機能する。制御部２１０は、ゲームプレイおよび動作指図データの配信に係る各種情報の送受信の仲介、並びに、ゲームの進行の支援のために、図示しないその他の機能ブロックとしても機能することができる。

通信仲介部２１１は、ユーザ端末１００、ＨＭＤセット１０００、および配信端末４００の間の各種情報の送受信を仲介する。例えば、通信仲介部２１１は、ＨＭＤセット１０００から受信したゲーム進行情報をユーザ端末１００へ送信する。ゲーム進行情報は、プレイヤによって操作されるキャラクタの動き、該キャラクタのパラメータ、該キャラクタが所持しているアイテムや武器、敵キャラクタなどの情報などを示すデータが含まれる。サーバ２００は、ゲーム進行情報を、ゲームに参加している全てのユーザのユーザ端末１００へ送信する。換言すれば、サーバ２００は、共通のゲーム進行情報をゲームに参加している全てのユーザのユーザ端末１００へ送信する。これにより、ゲームに参加している全てのユーザのユーザ端末１００それぞれにおいて、ＨＭＤセット１０００と同様にゲームが進行する。

また、例えば、通信仲介部２１１は、ユーザ端末１００のいずれかから受信した、プレイヤによるゲームの進行を支援するための情報を、その他のユーザ端末１００、および、ＨＭＤセット１０００へ送信する。該情報は、一例として、プレイヤがゲームを有利に進行するためのアイテムであって、プレイヤ（キャラクタ）に提供されるアイテムを示すアイテム情報であってもよい。アイテム情報は、アイテムを提供したユーザを示す情報（ユーザ名、ユーザＩＤなど）を含む。また、通信仲介部２１１は、配信端末４００からユーザ端末１００への動作指図データの配信を仲介してもよい。

ログ生成部２１２は、ＨＭＤセット１０００から受信するゲーム進行情報に基づいて、ゲーム進行のログを生成する。リスト生成部２１３は、ゲームプレイの終了後にユーザリスト２３４を生成する。詳細については後述するが、ユーザリスト２３４における各ユーザには、そのユーザが行ったプレイヤへの支援の内容を示すタグが関連付けられている。リスト生成部２１３は、ログ生成部２１２が生成したゲーム進行のログに基づいて、タグを生成し、該当するユーザに関連付ける。なお、リスト生成部２１３は、ゲームの運営者などがパーソナルコンピュータなどの端末装置を用いて入力した、各ユーザが行ったプレイヤへの支援の内容を、タグとして、該当するユーザに関連付けてもよい。これにより、各ユーザが行った支援の内容がより詳細なものとなる。なお、ユーザ端末１００は、ユーザがゲームに参加する際、ユーザの操作に基づいて、ユーザを示す情報をサーバ２００へ送信する。例えば、ユーザ端末１００は、ユーザが入力したユーザＩＤをサーバ２００へ送信する。つまり、サーバ２００は、ゲームに参加している全てのユーザについて、各ユーザを示す情報を保持している。リスト生成部２１３は、該情報を用いて、ユーザリスト２３４を生成すればよい。

（ＨＭＤセット１０００の機能的構成）
制御部３１０は、記憶部３２０に格納されたゲームプログラム３３１を実行することにより、ＨＭＤセット１０００を統括的に制御する。例えば、制御部３１０は、ゲームプログラム３３１、および、プレイヤの操作に従って、ゲームを進行させる。また、制御部３１０は、ゲームを進行させている間、必要に応じて、サーバ２００と通信して、情報の送受信を行う。制御部３１０は、情報の送受信を、サーバ２００を介さずにユーザ端末１００と直接行ってもよい。

制御部３１０は、ゲームプログラム３３１の記述に応じて、操作受付部３１１、表示制御部３１２、ＵＩ制御部３１３、アニメーション生成部３１４、ゲーム進行部３１５、仮想空間制御部３１６、および反応処理部３１７として機能する。制御部３１０は、実行されるゲームの性質に応じて、該ゲームに登場するキャラクタの制御などのために、図示しないその他の機能ブロックとしても機能することができる。

操作受付部３１１は、プレイヤの入力操作を検知し、受け付ける。操作受付部３１１は、ＨＭＤ５００、モーションセンサ５２０、コントローラ５４０などから入力された信号を受け付け、いかなる入力操作がなされたかを判別し、その結果を制御部３１０の各要素に出力する。

ＵＩ制御部３１３は、モニタ５１、ディスプレイ５３０などに表示させるユーザインターフェース（以下、ＵＩ）画像を制御する。ＵＩ画像は、プレイヤが、ゲームの進行上必要な入力をＨＭＤセット１０００に対して行うためのツール、または、ゲームの進行中に出力される情報をＨＭＤセット１０００から得るためのツールである。ＵＩ画像は、これには限定されないが、例えば、アイコン、ボタン、リスト、メニュー画面などである。

アニメーション生成部３１４は、各種オブジェクトの制御態様に基づいて、各種オブジェクトのモーションを示すアニメーションを生成する。例えば、アニメーション生成部３１４は、オブジェクト（例えば、プレイヤのアバターオブジェクト）がまるでそこにいるかのように動いたり、口を動かしたり、表情を変えたりする様子を表現したアニメーション等を生成してもよい。

ゲーム進行部３１５は、ゲームプログラム３３１、プレイヤによる入力操作、および、該入力操作に応じたアバターオブジェクトの動作などに基づいて、ゲームを進行する。例えば、ゲーム進行部３１５は、アバターオブジェクトが所定の動作を行った場合に、所定のゲーム処理を行う。また、例えば、ゲーム進行部３１５は、ユーザ端末１００におけるユーザの操作を表す情報を受信し、当該ユーザの操作に基づいてゲーム処理を行ってもよい。また、ゲーム進行部３１５は、ゲームの進行に従ってゲーム進行情報を生成し、サーバ２００へ送信する。該ゲーム進行情報は、サーバ２００を介してユーザ端末１００へ送信される。これにより、ＨＭＤセット１０００におけるゲームの進行が、ユーザ端末１００において共有される。換言すれば、ＨＭＤセット１０００におけるゲームの進行と、ユーザ端末１００におけるゲームの進行とが同期する。

仮想空間制御部３１６は、ゲームの進行に応じて、プレイヤに提供される仮想空間に関する各種の制御を行う。一例として、仮想空間制御部３１６は、各種オブジェクトを生成し、仮想空間に配置する。また、仮想空間制御部３１６は、仮想カメラを仮想空間に配置する。また、仮想空間制御部３１６は、ゲームの進行に応じて、仮想空間に配置した各種オブジェクトを動作させる。また、仮想空間制御部３１６は、ゲームの進行に応じて、仮想空間に配置した仮想カメラの位置、傾きを制御する。

表示制御部３１２は、モニタ５１、ディスプレイ５３０に対して、上述の各要素によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部３１２は、仮想空間に配置された仮想カメラからの視界に基づく画像を、ゲーム画面として、モニタ５１、ディスプレイ５３０に表示してもよい。また、表示制御部３１２は、アニメーション生成部３１４によって生成されたアニメーションを該ゲーム画面に含めてもよい。また、表示制御部３１２は、ＵＩ制御部３１３によって制御される上述のＵＩ画像を、該ゲーム画面に重畳して描画してもよい。

反応処理部３１７は、ユーザ端末１００のユーザによる、プレイヤのゲームプレイに対する反応についてフィードバックを受け付けて、これを、プレイヤに対して出力する。本実施形態では、例えば、ユーザ端末１００は、ユーザの入力操作に基づいて、アバターオブジェクトに宛てたコメント（メッセージ）を作成することができる。反応処理部３１７は、該コメントのコメントデータを受け付けて、これを出力する。反応処理部３１７は、ユーザのコメントに対応するテキストデータを、モニタ５１、ディスプレイ５３０に表示してもよいし、ユーザのコメントに対応する音声データを、図示しないスピーカから出力してもよい。前者の場合、反応処理部３１７は、上記テキストデータに対応する画像（すなわち、コメントの内容を含む画像）を、ゲーム画面に重畳して描画してもよい。

（ユーザ端末１００の機能的構成）
制御部１１０は、記憶部１２０に格納されたゲームプログラム１３１を実行することにより、ユーザ端末１００を統括的に制御する。例えば、制御部１１０は、ゲームプログラム１３１、および、ユーザの操作に従って、ゲームを進行させる。また、制御部１１０は、ゲームを進行させている間、必要に応じて、サーバ２００と通信して、情報の送受信を行う。制御部１１０は、情報の送受信を、サーバ２００を介さずにＨＭＤセット１０００と直接行ってもよい。

制御部１１０は、ゲームプログラム１３１の記述に応じて、操作受付部１１１、表示制御部１１２、ＵＩ制御部１１３、アニメーション生成部１１４、ゲーム進行部１１５、仮想空間制御部１１６、および動画再生部１１７として機能する。制御部１１０は、実行されるゲームの性質に応じて、ゲームの進行のために、図示しないその他の機能ブロックとしても機能することができる。

操作受付部１１１は、入力部１５１に対するユーザの入力操作を検知し受け付ける。操作受付部１１１は、タッチスクリーン１５およびその他の入出力ＩＦ１４を介したコンソールに対してユーザが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部１１０の各要素に出力する。

例えば、操作受付部１１１は、入力部１５１に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部１１１は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、ピンチイン／ピンチアウト操作、およびタップ操作等を特定する。また、操作受付部１１１は、連続して検知されていた入力が途切れると、タッチスクリーン１５から接触入力が解除されたことを検知する。

ＵＩ制御部１１３は、ユーザの入力操作、および、受信したゲーム進行情報の少なくとも何れかに応じて、ＵＩを構築するために表示部１５２に表示させるＵＩ画像を制御する。ＵＩ画像は、ユーザが、ゲームの進行上必要な入力をユーザ端末１００に対して行うためのツール、または、ゲームの進行中に出力される情報をユーザ端末１００から得るためのツールである。ＵＩ画像は、これには限定されないが、例えば、アイコン、ボタン、リスト、メニュー画面などである。

アニメーション生成部１１４は、各種オブジェクトの制御態様に基づいて、各種オブジェクトのモーションを示すアニメーションを生成する。

ゲーム進行部１１５は、ゲームプログラム１３１、受信したゲーム進行情報、および、ユーザによる入力操作などに基づいて、ゲームを進行する。ゲーム進行部１１５は、ユーザによる入力操作により、所定のゲーム処理を行った場合、該ゲーム処理に関する情報を、サーバ２００を介してＨＭＤセット１０００へ送信する。これにより、該所定のゲーム処理が、ＨＭＤセット１０００において共有される。換言すれば、ＨＭＤセット１０００におけるゲームの進行と、ユーザ端末１００におけるゲームの進行とが同期する。所定のゲーム処理とは、例えば、アバターオブジェクトにアイテムを提供する処理であり、この例の場合、ゲーム処理に関する情報は、上述したアイテム情報である。

仮想空間制御部１１６は、ゲームの進行に応じて、ユーザに提供される仮想空間に関する各種の制御を行う。一例として、仮想空間制御部１１６は、各種オブジェクトを生成し、仮想空間に配置する。また、仮想空間制御部１１６は、仮想カメラを仮想空間に配置する。また、仮想空間制御部１１６は、ゲームの進行、具体的には、受信したゲーム進行情報に応じて、仮想空間に配置した各種オブジェクトを動作させる。また、仮想空間制御部３１６は、ゲームの進行、具体的には、受信したゲーム進行情報に応じて、仮想空間に配置した仮想カメラの位置、傾きを制御する。

表示制御部１１２は、表示部１５２に対して、上述の各要素によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部１１２は、ユーザに提供される仮想空間に配置された仮想カメラからの視界に基づく画像を、ゲーム画面として、表示部１５２に表示してもよい。また、表示制御部１１２は、アニメーション生成部１１４によって生成されたアニメーションを該ゲーム画面に含めてもよい。また、表示制御部１１２は、ＵＩ制御部１１３によって制御される上述のＵＩ画像を、該ゲーム画面に重畳して描画してもよい。いずれにしても、表示部１５２に表示されるゲーム画面は、他のユーザ端末１００、および、ＨＭＤセット１０００にて表示されるゲーム画面と同様のゲーム画面である。

動画再生部１１７は、配信端末４００から受信した動作指図データを解析（レンダリング）し、動画を再生する。

（配信端末４００の機能的構成）
制御部４１０は、記憶部４２０に格納されたプログラム（不図示）を実行することにより、配信端末４００を統括的に制御する。例えば、制御部４１０は、該プログラム、および、配信端末４００のユーザ（本実施形態ではプレイヤ）の操作に従って、動作指図データを生成し、ユーザ端末１００に配信する。また、制御部４１０は、必要に応じて、サーバ２００と通信して、情報の送受信を行う。制御部４１０は、情報の送受信を、サーバ２００を介さずにユーザ端末１００と直接行ってもよい。

制御部４１０は、プログラムの記述に応じて、通信制御部４１１、表示制御部４１２、操作受付部４１３、音声受付部４１４、モーション特定部４１５、および動作指図データ生成部４１６として機能する。制御部４１０は、動作指図データの生成および配信のために、図示しないその他の機能ブロックとしても機能することができる。

通信制御部４１１は、サーバ２００、または、サーバ２００を介したユーザ端末１００との情報の送受信を制御する。通信制御部４１１は、一例として、サーバ２００からユーザリスト４２１を受信する。また、通信制御部４１１は、一例として、動作指図データをユーザ端末１００へ送信する。

表示制御部４１２は、表示部４５２に対して、各要素によって実行された処理結果が反映された各種画面を出力する。表示制御部４１２は、一例として、受信したユーザリスト２３４を含む画面を表示する。また、表示制御部４１２は、一例として、配信する動作指図データに含まれる、アバターオブジェクトを動作させるためのモーションデータを、プレイヤに選択させるためのモーションリスト４２２を含む画面を表示する。

操作受付部４１３は、入力部１５１に対するプレイヤの入力操作を検知し受け付ける。操作受付部１１１は、タッチスクリーン４５およびその他の入出力ＩＦ４４を介したコンソールに対してプレイヤが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部４１０の各要素に出力する。

例えば、操作受付部４１３は、入力部４５１に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部４１３は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、ピンチイン／ピンチアウト操作、およびタップ操作等を特定する。また、操作受付部４１３は、連続して検知されていた入力が途切れると、タッチスクリーン４５から接触入力が解除されたことを検知する。

音声受付部４１４は、配信端末４００の周囲で発生した音声を受け付け、該音声の音声データを生成する。音声受付部４１４は、一例として、プレイヤが発話した音声を受け付け、該音声の音声データを生成する。

モーション特定部４１５は、プレイヤの入力操作に応じて、モーションリスト４２２から、プレイヤが選択したモーションデータを特定する。

動作指図データ生成部４１６は、動作指図データを生成する。一例として、動作指図データ生成部４１６は、生成された音声データと、特定されたモーションデータとを含む動作指図データを生成する。

なお、図６に示すＨＭＤセット１０００、サーバ２００、およびユーザ端末１００の機能、並びに、図７に示す配信端末４００の機能は一例にすぎない。ＨＭＤセット１０００、サーバ２００、ユーザ端末１００、および配信端末４００の各装置は、他の装置が備える機能の少なくとも一部を備えていてもよい。さらに、ＨＭＤセット１０００、サーバ２００、ユーザ端末１００、および配信端末４００以外のさらに別の装置をシステム１の構成要素とし、該別の装置にシステム１における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ＨＭＤセット１０００、サーバ２００、ユーザ端末１００、および配信端末４００、並びに、それ以外の別の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。

＜仮想空間の制御処理＞
図８は、プレイヤに提供される仮想空間、および、ユーザ端末１００のユーザに提供される仮想空間の制御処理の流れの一例を示すフローチャートである。図９は、ある実施の形態に従う、プレイヤに提供される仮想空間６００Ａ、および、プレイヤが視認する視界画像を示す図である。図１０は、ある実施の形態に従う、ユーザ端末１００のユーザに提供される仮想空間６００Ｂ、および、ユーザが視認する視界画像を示す図である。なお以降、仮想空間６００Ａおよび６００Ｂを区別する必要が無い場合、「仮想空間６００」と記載する。

ステップＳ１において、プロセッサ３０は、仮想空間制御部３１６として、図９に示す仮想空間６００Ａを規定する。プロセッサ３０は、仮想空間データ（不図示）を用いて、仮想空間６００Ａを規定する。仮想空間データは、ゲームプレイ端末３００に記憶されていてもよいし、プロセッサ３０が、ゲームプログラム３３１に基づいて生成してもよいし、プロセッサ３０が、サーバ２００などの外部の装置から取得してもよい。

仮想空間６００は、一例として、中心として定義された点の３６０度方向の全体を覆う全天球状の構造を有する。図９および図１０では、説明を複雑にしないために、仮想空間６００のうちの上半分の天球が例示されている。

ステップＳ２において、プロセッサ３０は、仮想空間制御部３１６として、仮想空間６００Ａに、アバターオブジェクト６１０（キャラクタ）を配置する。アバターオブジェクト６１０は、プレイヤに関連付けられたアバターオブジェクトであり、プレイヤの入力操作に従って動作する。

ステップＳ３において、プロセッサ３０は、仮想空間制御部３１６として、仮想空間６００Ａに、その他のオブジェクトを配置する。図９の例では、プロセッサ３０は、オブジェクト６３１～６３４を配置する。その他のオブジェクトは、例えば、ゲームプログラム３３１に従って動作するキャラクタオブジェクト（いわゆるノンプレイヤキャラクタ、ＮＰＣ）、仮想手などの操作オブジェクト、ゲームの進行に従って配置される動物、植物、人工物、自然物などを模したオブジェクトなどを含み得る。

ステップＳ４において、プロセッサ３０は、仮想空間制御部３１６として、仮想空間６００Ａに仮想カメラ６２０Ａを配置する。プロセッサ３０は、一例として、仮想カメラ６２０Ａを、アバターオブジェクト６１０の頭部の位置に配置する。

ステップＳ５において、プロセッサ３０は、視界画像６５０をモニタ５１およびディスプレイ５３０に表示する。プロセッサ３０は、仮想カメラ６２０Ａの初期の位置と傾きとに応じて、仮想空間６００Ａにおける仮想カメラ６２０Ａからの視界である視界領域６４０Ａを定義する。そして、プロセッサ３０は、視界領域６４０Ａに対応する視界画像６５０を定義する。プロセッサ３０は、視界画像６５０をモニタ５１およびディスプレイ５３０に出力することによって、視界画像６５０をＨＭＤ５００およびディスプレイ５３０に表示させる。

図９の例において、図９（Ａ）に示すように、オブジェクト６３４の一部が視界領域６４０Ａに含まれているため、視界画像６５０は、図９（Ｂ）に示すようにオブジェクト６３４の一部を含む。

ステップＳ６において、プロセッサ３０は、初期配置情報を、サーバ２００を介してユーザ端末１００へ送信する。初期配置情報とは、仮想空間６００Ａにおける各種オブジェクトの初期の配置位置を示す情報である。図９の例において、初期配置情報は、アバターオブジェクト６１０、および、オブジェクト６３１～６３４の初期の配置位置の情報を含む。初期配置情報は、ゲーム進行情報の１つであると表現することもできる。

ステップＳ７において、プロセッサ３０は、仮想空間制御部３１６として、ＨＭＤ５００の動きに応じて仮想カメラ６２０Ａを制御する。具体的には、プロセッサ３０は、ＨＭＤ５００の動き、すなわち、プレイヤの頭部の姿勢に応じて、仮想カメラ６２０Ａの向きおよび傾きを制御する。後述のように、プロセッサ３０は、プレイヤが頭部を動かす（頭部の姿勢を変更する）と、この動きに合わせて、アバターオブジェクト６１０の頭部を動かす。プロセッサ３０は、例えば、アバターオブジェクト６１０の視線の方向と、仮想カメラ６２０Ａの視線の方向とが一致するように、仮想カメラ６２０Ａの向きおよび傾きを制御する。ステップＳ８において、プロセッサ３０は、仮想カメラ６２０Ａの向きおよび傾きが変更されたことに応じて、視界画像６５０を更新する。

ステップＳ９において、プロセッサ３０は、仮想空間制御部３１６として、プレイヤの動きに応じて、アバターオブジェクト６１０を動かす。一例として、プロセッサ３０は、プレイヤが現実空間で移動したことに応じて、仮想空間６００Ａでアバターオブジェクト６１０を移動させる。また、プロセッサ３０は、プレイヤが現実空間で頭部を動かしたことに応じて、仮想空間６００Ａでアバターオブジェクト６１０の頭部を動かす。

ステップＳ１０において、プロセッサ３０は、仮想空間制御部３１６として、仮想カメラ６２０Ａを、アバターオブジェクト６１０に追随するように移動させる。つまり、仮想カメラ６２０Ａは、アバターオブジェクト６１０が移動しても、常にアバターオブジェクト６１０の頭部の位置にある。

プロセッサ３０は、仮想カメラ６２０Ａの移動に応じて、視界画像６５０を更新する。つまり、プロセッサ３０は、プレイヤの頭部の姿勢と、仮想空間６００Ａにおける仮想カメラ６２０Ａの位置とに応じて、視界領域６４０Ａを更新する。その結果、視界画像６５０が更新される。

ステップＳ１１において、プロセッサ３０は、アバターオブジェクト６１０の動作指図データを、サーバ２００を介してユーザ端末１００へ送信する。ここでの動作指図データは、仮想体験中（例えば、ゲームプレイ中）において、プレイヤの動作を取り込んだモーションデータ、プレイヤが発話した音声の音声データ、コントローラ５４０に対する入力操作の内容を示す操作データの少なくとも何れかを含む。プレイヤがゲームをプレイしている場合、動作指図データは、例えば、ゲーム進行情報としてユーザ端末１００へ送信される。

ステップＳ７～Ｓ１１の処理は、プレイヤがゲームをプレイしている間、継続して繰り返し実行される。

ステップＳ２１において、ユーザ３のユーザ端末１００のプロセッサ１０は、仮想空間制御部１１６として、図１０に示す仮想空間６００Ｂを規定する。プロセッサ１０は、仮想空間データ（不図示）を用いて、仮想空間６００Ｂを規定する。仮想空間データは、ユーザ端末１００に記憶されていてもよいし、プロセッサ１０が、ゲームプログラム１３１に基づいて生成してもよいし、プロセッサ１０が、サーバ２００などの外部の装置から取得してもよい。

ステップＳ２２において、プロセッサ１０は、初期配置情報を受信する。ステップＳ２３において、プロセッサ１０は、仮想空間制御部１１６として、初期配置情報に応じて各種オブジェクトを仮想空間６００Ｂに配置する。図１０の例の場合、各種オブジェクトは、アバターオブジェクト６１０、および、オブジェクト６３１～６３４である。

ステップＳ２４において、プロセッサ１０は、仮想空間制御部１１６として、仮想空間６００Ｂに仮想カメラ６２０Ｂを配置する。プロセッサ１０は、一例として、仮想カメラ６２０Ｂを、図１０（Ａ）に示す位置に配置する。

ステップＳ２５において、プロセッサ１０は、視界画像６６０を表示部１５２に表示する。プロセッサ１０は、仮想カメラ６２０Ｂの初期の位置と傾きとに応じて、仮想空間６００Ｂにおける仮想カメラ６２０Ｂからの視界である視界領域６４０Ｂを定義する。そして、プロセッサ１０は、視界領域６４０Ｂに対応する視界画像６６０を定義する。プロセッサ１０は、視界画像６６０を表示部１５２に出力することによって、視界画像６６０を表示部１５２に表示させる。

図１０の例において、図１０（Ａ）に示すように、アバターオブジェクト６１０およびオブジェクト６３１が視界領域６４０Ｂに含まれているため、視界画像６６０は、図１０（Ｂ）に示すようにアバターオブジェクト６１０およびオブジェクト６３１を含む。

ステップＳ２６において、プロセッサ１０は、動作指図データを受信する。ステップＳ２７において、プロセッサ１０は、仮想空間制御部１１６として、動作指図データに応じて、仮想空間６００Ｂでアバターオブジェクト６１０を動かす。換言すれば、プロセッサ１０は、リアルタイムレンダリングにより、アバターオブジェクト６１０が動作している映像を再生する。

ステップＳ２８において、プロセッサ１０は、仮想空間制御部１１６として、操作受付部１１１として受け付けたユーザの操作に応じて仮想カメラ６２０Ｂを制御する。ステップＳ２９において、プロセッサ１０は、仮想カメラ６２０Ｂの仮想空間６００Ｂにおける位置、仮想カメラ６２０Ｂの向きおよび傾きが変更されたことに応じて、視界画像６６０を更新する。なお、ステップＳ２８において、プロセッサ１０は、アバターオブジェクト６１０の動き、例えば、アバターオブジェクト６１０の移動や、向きの変更に応じて仮想カメラ６２０Ｂを自動的に制御してもよい。例えば、プロセッサ１０は、常にアバターオブジェクト６１０を正面から撮影するように自動的に仮想カメラ６２０Ｂを移動させたり、向きおよび傾きを変更したりしてもよい。また、一例として、プロセッサ１０は、アバターオブジェクト６１０の動きに応じて、常にアバターオブジェクト６１０を後方から撮影するように自動的に仮想カメラ６２０Ｂを移動させたり、向きおよび傾きを変更したりしてもよい。

このように、仮想空間６００Ａにおいて、アバターオブジェクト６１０は、プレイヤの動きに応じて動作する。この動作を示す動作指図データは、ユーザ端末１００に送信される。仮想空間６００Ｂにおいて、アバターオブジェクト６１０は、受信した動作指図データに応じて動作する。これにより、仮想空間６００Ａと仮想空間６００Ｂとにおいて、アバターオブジェクト６１０は同様の動作を行う。換言すれば、ユーザ３は、ユーザ端末１００を用いて、プレイヤの動作に応じたアバターオブジェクト６１０の動作を視認することができる。

＜ゲーム概要＞
図１１は、ユーザ端末１００において表示される視界画像の他の例を示す図である。具体的には、プレイヤがプレイしている、システム１が実行するゲーム（本ゲーム）のゲーム画面の一例を示す図である。

本ゲームは、一例として、銃、ナイフなどの武器を操作するアバターオブジェクト６１０と、ＮＰＣである複数の敵オブジェクト６７１とを仮想空間６００に登場させ、アバターオブジェクト６１０に敵オブジェクト６７１との対戦を行わせるゲームである。アバターオブジェクト６１０の体力、使用可能なマガジンの数、銃の残弾数、敵オブジェクト６７１の残数等の各種ゲームパラメータは、ゲームの進行に応じて更新される。

本ゲームには、複数のステージが用意されており、プレイヤは、各ステージに関連付けられている所定の達成条件を成立させることにより、当該ステージをクリアすることができる。所定の達成条件としては、例えば、出現する敵オブジェクト６７１をすべて倒すことや、出現する敵オブジェクト６７１のうちボスオブジェクトを倒すこと、所定のアイテムを獲得すること、所定位置に到達することなどにより成立する条件を含むものであってもよい。該達成条件は、ゲームプログラム１３１内で定義されている。なお、本ゲームでは、ゲームの内容に即し、達成条件が成立された場合にプレイヤはステージをクリア、換言すれば、アバターオブジェクト６１０の敵オブジェクト６７１への勝利（アバターオブジェクト６１０と敵オブジェクト６７１との間の勝敗）が決定される。これに対し、例えば、システム１で実行されるゲームがレースゲーム等である場合、ゴールに到達するという条件が成立した場合に、アバターオブジェクト６１０の順位が決定される。

本ゲームでは、ＨＭＤセット１０００及び複数のユーザ端末１００の間で仮想空間を共有するために、ゲーム進行情報が、所定時間毎に複数のユーザ端末１００にライブ配信される。この結果、ゲームを視聴中のユーザ端末１００のタッチスクリーン１５には、ユーザ端末１００に対応する仮想カメラ６２０Ｂによって規定される視界領域の視界画像が表示される。また、視界画像の右上段および左上段には、アバターオブジェクト６１０の体力、使用可能なマガジンの数、銃の残弾数、敵オブジェクト６７１の残数等を表すパラメータ画像が重畳的に表示される。この視界画像は、ゲーム画面と表現することもできる。

ゲーム進行情報は、上述したとおり、プレイヤの動作を取り込んだモーションデータ、プレイヤが発話した音声の音声データ、コントローラ５４０に対する入力操作の内容を示す操作データを含む。これらのデータはすなわち、アバターオブジェクト６１０の位置、姿勢、向きなどを特定するための情報、敵オブジェクト６７１の位置、姿勢、向きなどを特定する情報、その他オブジェクト（例えば、障害物オブジェクト６７２、６７３）の位置などを特定する情報である。プロセッサ１０は、ゲーム進行情報を解析（レンダリング）することにより、各オブジェクトの位置、姿勢、向きなどを特定する。

ゲーム情報１３２は、アバターオブジェクト６１０、敵オブジェクト６７１、障害物オブジェクト６７２、６７３等の各種オブジェクトのデータを含む。プロセッサ１０は、該データと、ゲーム進行情報の解析結果とを用いて、各オブジェクトの位置、姿勢、向きなどを更新する。これにより、ゲームが進行し、仮想空間６００Ｂにおける各オブジェクトは、仮想空間６００Ａにおける各オブジェクトと同様に動く。具体的には、仮想空間６００Ｂにおいて、アバターオブジェクト６１０を含む各オブジェクトは、ユーザ端末１００に対するユーザからの操作の有無に関わらず、ゲーム進行情報に基づいて動作する。

ユーザ端末１００のタッチスクリーン１５においては、一例として、ＵＩ画像７０１および７０２が、視界画像に重畳して表示される。ＵＩ画像７０１は、アバターオブジェクト６１０を支援するためのアイテム投入操作をユーザ３から受け付けるＵＩ画像７１１を、タッチスクリーン１５に表示するための操作を受け付けるＵＩ画像である。ＵＩ画像７０２は、アバターオブジェクト６１０（換言すれば、プレイヤ４）に対するコメントを入力し、送信するための操作をユーザ３から受け付けるＵＩ画像（後述）を、タッチスクリーン１５に表示するための操作を受け付けるＵＩ画像である。ＵＩ画像７０１および７０２が受け付ける操作は、例えば、ＵＩ画像７０１および７０２をタップする操作であってもよい。

ＵＩ画像７０１がタップされると、ＵＩ画像７１１が、視界画像に重畳して表示される。ＵＩ画像７１１は、例えば、マガジンのアイコンが描かれたＵＩ画像７１１Ａ、救急箱のアイコンが描かれたＵＩ画像７１１Ｂ、三角コーンのアイコンが描かれたＵＩ画像７１１Ｃ、バリケードのアイコンが描かれたＵＩ画像７１１Ｄを含む。アイテム投入操作は、例えば、いずれかのＵＩ画像をタップする操作に相当する。

一例として、ＵＩ画像７１１Ａがタップされると、アバターオブジェクト６１０が使用する銃の残弾数が増加する。ＵＩ画像７１１Ｂがタップされると、アバターオブジェクト６１０の体力が回復する。ＵＩ画像７１１Ｃおよび７１１Ｄがタップされると、敵オブジェクト６７１の移動を妨害する障害物オブジェクト６７２、６７３が仮想空間に配置される。障害物オブジェクト６７２、６７３は、一方が他方に比べて、敵オブジェクト６７１の移動をより妨害するものであってもよい。

プロセッサ１０は、アイテム投入操作が行われたことを示すアイテム投入情報を、サーバ２００へ送信する。アイテム投入情報には、アイテム投入操作により指定されたアイテムの種別を特定するための情報が少なくとも含まれる。アイテム投入情報には、アイテムが配置される位置を示す情報など、アイテムに関するその他の情報が含まれていてもよい。アイテム投入情報は、サーバ２００を介して、他のユーザ端末１００、および、ＨＭＤセット１０００へ送信される。

図１２は、ユーザ端末１００において表示される視界画像の他の例を示す図である。具体的には、本ゲームのゲーム画面の一例を示す図であり、ゲームプレイ中のプレイヤとユーザ端末１００とのコミュニケーションについて説明するための図である。

図１２（Ａ）の例において、ユーザ端末１００は、アバターオブジェクト６１０に発話６９１を実行させている。具体的には、ユーザ端末１００は、ゲーム進行情報に含まれる音声データに従って、アバターオブジェクト６１０に発話６９１を実行させている。発話６９１の内容は、プレイヤ４が発話した「弾が無いよー！」というものである。すなわち、発話６９１の内容は、マガジンが０、銃に装填した銃弾が１となったことにより、敵オブジェクト６７１を攻撃する手段を失いそうであることを各ユーザに伝えるものである。

なお、図１２（Ａ）では、アバターオブジェクト６１０の発話を視覚的に示すため吹き出しを用いているが、実際は、ユーザ端末１００のスピーカから音声が出力される。なお、音声出力とともに、図１２（Ａ）に示す吹き出し（すなわち、音声の内容のテキストを含む吹き出し）が視界画像中に表示されてもよい。これは、後述する発話６９２でも同様である。

ＵＩ画像７０２に対するタップ操作を受け付けると、ユーザ端末１００は、図１２（Ｂ）に示すように、ＵＩ画像７０５および７０６（メッセージＵＩ）を視界画像に重畳して表示する。ＵＩ画像７０５は、アバターオブジェクト６１０（換言すれば、プレイヤ）に対するコメントを表示するＵＩ画像である。ＵＩ画像７０６は、入力されたコメントを送信するためコメント送信操作をユーザ３から受け付けるＵＩ画像である。

ユーザ端末１００は、一例として、ＵＩ画像７０５へのタップ操作を受け付けると、キーボードを模したＵＩ画像（不図示、以下、単に「キーボード」と記載）をタッチスクリーン１５に表示させる。ユーザ端末１００は、キーボードに対するユーザの入力操作に応じたテキストを、ＵＩ画像７０５に表示させる。図１２（Ｂ）の例では、「マガジン送るね」というテキストがＵＩ画像７０５に表示されている。

ユーザ端末１００は、テキスト入力後に、一例として、ＵＩ画像７０６へのタップ操作を受け付けると、入力した内容（テキストの内容）を示す情報と、ユーザを示す情報とを含むコメント情報をサーバ２００へ送信する。コメント情報は、サーバ２００を介して、他のユーザ端末１００、および、ＨＭＤセット１０００へ送信される。

ＵＩ画像７０３Ａは、コメントを送信したユーザのユーザ名を示すＵＩ画像であり、ＵＩ画像７０４Ａは、該ユーザが送信したコメントの内容を示すＵＩ画像である。図１２（Ｂ）の例では、ユーザ名が「ＢＢＢＢＢ」であるユーザが、自身のユーザ端末１００を用い、「危ない！」という内容のコメント情報を送信したことにより、ＵＩ画像７０３ＡおよびＵＩ画像７０４Ａが表示されている。ＵＩ画像７０３ＡおよびＵＩ画像７０４Ａは、本ゲームに参加しているすべてのユーザ端末１００のタッチスクリーン１５、および、ＨＭＤ５００のモニタ５１に表示される。なお、ＵＩ画像７０３Ａおよび７０４Ａは、１つのＵＩ画像であってもよい。すなわち、１つのＵＩ画像にユーザ名とコメントの内容とが含まれていてもよい。

図１２（Ｃ）の例では、図１２に示すユーザ端末１００のユーザである、「ＡＡＡＡＡ」というユーザ名のユーザが、上述したとおりコメントを入力し、送信したことにより、タッチスクリーン１５にＵＩ画像７０３Ｂおよび７０４Ｂが表示されている。ＵＩ画像７０３Ｂにはユーザ名「ＡＡＡＡＡ」が含まれており、ＵＩ画像７０４Ｂには、図１２（Ｂ）の例において入力された「マガジン送るね！」とのコメントが含まれている。

また、図１２（Ｃ）の例は、ユーザ「ＡＡＡＡＡ」がさらに、ＵＩ画像７０１へのタップ操作を入力し、ＵＩ画像７１１をタッチスクリーン１５に表示させ、ＵＩ画像７１１Ａへのタップ操作を入力した後の視界画像６１１である。つまり、ユーザ「ＡＡＡＡＡ」のユーザ端末１００から、他のユーザ端末１００およびＨＭＤセット１０００に、マガジンを示すアイテム投入情報が送信された結果、ユーザ端末１００およびＨＭＤセット１０００は、演出オブジェクト６７４（後述）を仮想空間６００に配置している。一例として、ユーザ端末１００およびＨＭＤセット１０００は、アイテム投入情報にて示された経過時間が経過した後に、演出オブジェクト６７４に関する演出を実行し、アイテムオブジェクトの効果を発動させる処理を実行する。

図１２（Ｄ）の例では、アイテムオブジェクトの効果を発動させる処理の実行により、マガジンの数が０から１に増加している。この結果、プレイヤは、ユーザ「ＡＡＡＡＡ」に対して、「ありがとう！」と発話し、該発話の音声データが、各ユーザ端末１００に送信される。これにより、各ユーザ端末１００は、アバターオブジェクト６１０の発話６９２として、「ありがとう！」という音声を出力する。

以上のように、本ゲームにおいては、プレイヤの発話に基づくアバターオブジェクト６１０の発話音声の出力と、各ユーザによるコメントの入力とにより、ユーザとアバターオブジェクト６１０とのコミュニケーションが実現される。

（ゲームプレイ端末３００におけるゲーム進行処理）
図１３は、ゲームプレイ端末３００で実行されるゲーム進行処理の流れの一例を示すフローチャートである。

ステップＳ３１において、プロセッサ３０は、ゲーム進行部３１５として、ゲームプログラム３３１とプレイヤの動きとに基づいてゲームを進行させる。ステップＳ３２において、プロセッサ３０は、ゲーム進行情報を生成し、ユーザ端末１００へ配信する。具体的には、プロセッサ３０は、生成したゲーム進行情報を、サーバ２００を介して、各ユーザ端末１００へ送信する。

ステップＳ３３において、プロセッサ３０は、アイテム投入情報を受信すると（Ｓ３３でＹＥＳ）、ステップＳ３４において、アイテム投入情報に基づいて、アイテムオブジェクトを仮想空間６００Ａに配置する。一例として、プロセッサ３０は、アイテムオブジェクトの配置の前に、演出オブジェクト６７４を仮想空間６００Ａに配置する（図１１（Ｃ）参照）。演出オブジェクト６７４は、例えば、プレゼント箱を模したオブジェクトであってもよい。プロセッサ３０は、一例として、アイテム投入情報にて示された経過時間が経過した後に、演出オブジェクト６７４に関する演出を実行してもよい。該演出は、例えば、プレゼント箱の蓋が開くアニメーションであってもよい。プロセッサ３０は、該アニメーションの実行の後、アイテムオブジェクトの効果を発動させる処理を実行する。例えば、図１１（Ｄ）の例では、障害物オブジェクト６７３を配置する。

プロセッサ３０は、アニメーションの実行の後、タップ操作されたＵＩ画像に対応するアイテムオブジェクトを仮想空間６００Ａに配置してもよい。例えば、ＵＩ画像７１１Ａに対してタップ操作が行われた場合、プロセッサ３０は、アニメーションの実行の後、マガジンを示すマガジンオブジェクトを仮想空間６００Ａに配置する。また、ＵＩ画像７１１Ｂに対してタップ操作が行われた場合、プロセッサ３０は、アニメーションの実行の後、救急箱を示す救急箱オブジェクトを仮想空間６００Ａに配置する。プロセッサ３０は、例えば、マガジンオブジェクトまたは救急箱オブジェクトの位置に、アバターオブジェクト６１０が移動した場合に、マガジンオブジェクトまたは救急箱オブジェクトの効果を発動させる処理を実行してもよい。

プロセッサ３０は、ゲームが終了するまで、ステップＳ３１～Ｓ３４の処理を継続し、繰り返す。ゲームが終了した場合、例えば、プレイヤがゲームを終了するための所定の入力操作を入力した場合（ステップＳ３５でＹＥＳ）、図１３に示す処理は終了する。

（ユーザ端末１００におけるゲーム進行処理）
図１４は、ユーザ端末１００で実行されるゲーム進行処理の流れの一例を示すフローチャートである。

ステップＳ４１において、プロセッサ１０は、ゲーム進行情報を受信する。ステップＳ４２において、プロセッサ１０は、ゲーム進行部１１５として、ゲーム進行情報に基づいてゲームを進行させる。

ステップＳ４３において、プロセッサ１０が、ユーザ３によるアイテム投入操作を受け付けると（ステップＳ４３にてＹＥＳ）、ステップＳ４４において、プロセッサ１０は、仮想通貨を消費し、演出オブジェクト６７４を仮想空間６００Ｂに配置する。ここで、仮想通貨は、ゲームへの参加の前、あるいは、ゲームへの参加中に、ユーザ３がプロセッサ１０に対し所定の操作を行うことにより購入（本ゲームに対して課金）されるものであってもよいし、所定の条件を満たした場合にユーザ３に付与されるものであってもよい。所定の条件とは、本ゲームにおけるクエストのクリア等、本ゲームへの参加が必要なものであってもよいし、アンケートに答える等、本ゲームへの参加が不要なものであってもよい。仮想通貨の金額（仮想通貨の所有量）は、一例として、ゲーム情報１３２としてユーザ端末１００に記憶される。

ステップＳ４５において、プロセッサ１０は、アイテム投入情報をサーバ２００へ送信する。アイテム投入情報は、サーバ２００を介してゲームプレイ端末３００へ送信される。

プロセッサ１０は、演出オブジェクト６７４の配置後、所定時間が経過すると、アイテムオブジェクトを仮想空間６００Ａに配置する。図１１の例では、障害物オブジェクト６７３を配置する。つまり、ユーザ３が、ＵＩ画像７１１Ｃへのタップ操作を入力することにより、所定量の仮想通貨が消費され、障害物オブジェクト６７３が配置される。

プロセッサ１０は、ゲームが終了するまで、ステップＳ４１～Ｓ４５の処理を継続し、繰り返す。ゲームが終了した場合、例えば、プレイヤがゲームを終了するための所定の入力操作を行った場合や、ユーザ３が、ゲームから途中退席するための所定の入力操作を行った場合（ステップＳ４６でＹＥＳ）、図１４に示す処理は終了する。

（サーバ２００におけるゲーム進行処理）
図１５は、サーバ２００で実行されるゲーム進行処理の流れの一例を示すフローチャートである。

ステップＳ５１において、プロセッサ２０は、ゲーム進行情報をゲームプレイ端末３００から受信する。ステップＳ５２において、プロセッサ２０は、ログ生成部２１２として、ゲーム進行のログ（以下、プレイログ）を更新する。なお、プレイログは、一例として、ゲームプレイ端末３００から初期配置情報を受信したとき、プロセッサ２０が生成する。

ステップＳ５３において、プロセッサ２０は、受信したゲーム進行情報を、各ユーザ端末１００へ送信する。

ステップＳ５４において、アイテム投入情報をいずれかのユーザ端末１００から受信した場合（ステップＳ５４にてＹＥＳ）、ステップＳ５５において、プロセッサ２０は、ログ生成部２１２としてプレイログを更新する。ステップＳ５６において、プロセッサ２０は、受信したアイテム投入情報をゲームプレイ端末３００へ送信する。

プロセッサ２０は、ゲームが終了するまで、ステップＳ５１～Ｓ５６の処理を継続し、繰り返す。ゲームが終了した場合、例えば、ゲームプレイ端末３００から、ゲームが終了したことを示す情報を受信した場合（ステップＳ５７でＹＥＳ）、ステップＳ５８において、プロセッサ２０は、リスト生成部２１３として、プレイログからゲームに参加したユーザのリスト（ユーザリスト２３４）を生成する。プロセッサ２０は、生成したユーザリスト２３４を、サーバ２００に記憶する。

図１６は、ユーザリスト２３４の一具体例を示す図である。「ユーザ」のカラムには、ゲームに参加した各ユーザを示す情報（例えば、ユーザ名）が格納されている。「タグ」のカラムには、各ユーザがプレイヤに対して行った支援に基づいて生成された情報（タグ）が格納されている。図１６の例において、「タグ」のカラムに格納されたタグのうち、鍵括弧を有さないものは、プロセッサ２０が自動生成した情報であり、鍵括弧を有するものは、ゲームの運営者が手動で入力した情報である。

図１６の例において、ユーザ「ＡＡＡＡＡ」には、マガジン、１０Ｆ、ボス、「マガジンのプレゼントによりボスに勝利」という情報が対応付けられている。これは、例えば、１０Ｆというステージでのボス戦において、ユーザ「ＡＡＡＡＡ」がマガジンを投入し、その投入されたマガジンの銃弾でアバターオブジェクト６１０がボスに勝利したことを示している。

また、ユーザ「ＢＢＢＢＢ」には、救急箱、３Ｆ、ザコ、「ゲームオーバー寸前で回復」という情報が対応付けられている、これは、例えば、３Ｆというステージのザコ敵との戦闘において、ユーザ「ＢＢＢＢＢ」が救急箱を投入し、その結果、アバターオブジェクト６１０の体力が０になる（ゲームオーバーになる）寸前で体力が回復したことを示している。

また、ユーザ「ＣＣＣＣＣ」には、バリケード、５Ｆ、ザコ、「バリケードでゾンビを二人足止め」という情報が対応付けられている。これは、例えば、５Ｆというステージのザコ敵との戦闘において、ユーザ「ＣＣＣＣＣ」がバリケード（図１１における障害物オブジェクト６７２）を投入し、その結果、二人のザコ敵の足止めに成功したことを示している。

図１６の例では、各ユーザ３のユーザ名に対し、行った支援が１つ対応付けられているが、支援を複数回行なったユーザ３のユーザ名には、複数回の支援それぞれのタグが対応付けられる。ユーザリスト２３４において、該それぞれのタグは区別されていることが好ましい。これにより、ゲーム終了後に、配信端末４００を用いてユーザリスト４２１を参照するプレイヤが、各支援の内容を正確に把握できる。

＜動作指図データの配信＞
（配信端末４００における配信処理）
図１７は、配信端末４００で実行される配信処理の流れの一例を示すフローチャートである。図１８は、配信端末４００に表示される画面の一具体例を示す図である。図１９は、配信端末に表示される画面の他の具体例を示す図である。

ステップＳ６１において、プロセッサ４０は、操作受付部４１３として、ゲームに参加したユーザのリスト（ユーザリスト２３４）を表示するための第１操作を受け付ける。図１８（Ａ）に示すダウンロード画面７２１は、ユーザリスト２３４をサーバ２００からダウンロードし、表示部４５２に表示させるための画面である。ダウンロード画面７２１は、一例として、図１７に示す配信処理を実行するアプリケーションの起動操作を、配信端末４００に入力した直後に表示される画面である。

ダウンロード画面７２１は、一例として、ＵＩ画像７２２および７２３を含む。ＵＩ画像７２２は、ユーザリスト２３４をダウンロードするための操作、すなわち、上記第１操作を受け付ける。第１操作は、例えば、ＵＩ画像７２２をタップする操作であってもよい。ＵＩ画像７２３は、アプリケーションを終了するための操作を受け付ける。該操作は、例えば、ＵＩ画像７２３をタップする操作であってもよい。

ＵＩ画像７２２に対するタップ操作を受け付けると、ステップＳ６２において、プロセッサ４０は、通信制御部４１１として、ユーザリスト２３４をサーバ２００から取得（受信）する。ステップＳ６３において、プロセッサ４０は、表示制御部４１２として、ユーザリスト２３４を表示部４５２に表示させる。具体的には、プロセッサ４０は、ユーザリスト２３４に基づいて生成されたユーザリスト画面を、表示部４５２に表示させる。ユーザリスト画面は、一例として、図１８（Ｂ）に示すユーザリスト画面７３１であってもよい。ユーザリスト画面７３１は、ユーザリスト２３４における各レコードに対応するレコード画像からなる。図１８（Ｂ）の例では、レコード画像として、レコード画像７３２Ａ～７３２Ｃを記載しているが、レコード画像の数は３つに限定されない。図１８（Ｂ）の例において、ユーザリスト２３４におけるレコードの数が３より多い（すなわち、ゲームに参加したユーザの人数が３人より多い）場合、プレイヤは、例えば画面をスクロールする操作（例えば、ドラッグ操作やフリック操作）をタッチスクリーン４５に入力することにより、他のレコード画像を表示部４５２に表示させることができる。

一例として、レコード画像７３２Ａ～７３２Ｃは、それぞれ、ユーザ名７３３Ａ～７３３Ｃ、タグ情報７３４Ａ～７３４Ｃ、および、アイコン７３５Ａ～７３５Ｃを含む。以降、レコード画像７３２Ａ～７３２Ｃ、ユーザ名７３３Ａ～７３３Ｃ、タグ情報７３４Ａ～７３４Ｃ、および、アイコン７３５Ａ～７３５Ｃについて、区別する必要が無い場合、それぞれ、「レコード画像７３２」、「ユーザ名７３３」、「タグ情報７３４」、「アイコン７３５」と記載する。

ユーザ名７３３は、ユーザリスト２３４において、「ユーザ」のカラムに格納されている、ゲームに参加した各ユーザを示す情報である。タグ情報７３４は、ユーザリスト２３４において、ゲームに参加した各ユーザを示す情報のそれぞれに対応付けられているタグを示す情報である。例えば、レコード画像７３２Ａは、ユーザ名７３３Ａとして、「ＡＡＡＡＡ」を含む。このため、レコード画像７３２Ａは、タグ情報７３４Ａとして、ユーザリスト２３４において「ＡＡＡＡＡ」に対応付けられている、『マガジン、１０Ｆ、ボス、「マガジンのプレゼントによりボスに勝利」』を含む。アイコン７３５は、例えば、ユーザが事前に設定した画像である。

なお、プロセッサ４０は、受信したユーザリストを配信端末４００に記憶してもよい（図７のユーザリスト４２１）。ダウンロード画面７２１は、ユーザリスト４２１を表示部４５２に表示するためのＵＩ画像（不図示）を含んでいてもよい。この例において、該ＵＩ画像がタップされた場合、プロセッサ４０は、ユーザリスト２３４のダウンロードを行わず、ユーザリスト４２１を読み出し、該ユーザリスト４２１からユーザリスト画面を生成し、表示部４５２に表示させる。

ステップＳ６４において、プロセッサ４０は、操作受付部４１３として、ユーザリスト画面７３１に含まれるユーザの何れかを選択するための第２操作を受け付ける。第２操作は、一例として、ユーザリスト画面７３１におけるレコード画像７３２の何れかをタップする操作であってもよい。図１８（Ｂ）の例では、プレイヤは、レコード画像７３２Ａへのタップ操作を入力している。すなわち、プレイヤは、動作指図データを配信するユーザとしてユーザ「ＡＡＡＡＡ」を選択している。

レコード画像７３２に対するタップ操作を受け付けると、ステップＳ６５において、プロセッサ４０は、表示制御部４１２として、モーションリスト４２２を表示部４５２に表示させる。具体的には、プロセッサ４０は、モーションリスト４２２に基づいて生成されたモーションリスト画面を、表示部４５２に表示させる。モーションリスト画面は、一例として、図１９に示すモーションリスト画面７４１であってもよい。モーションリスト画面７４１は、モーションリスト４２２における各レコードに対応するレコード画像からなる。図１９の例では、レコード画像として、レコード画像７４２Ａ～７４２Ｃを記載しているが、レコード画像の数は３つに限定されない。図１９の例において、モーションリスト４２２におけるレコードの数が４より多い場合、プレイヤは、例えば画面をスクロールする操作（例えば、ドラッグ操作やフリック操作）をタッチスクリーン４５に入力することにより、他のレコード画像を表示部４５２に表示させることができる。

一例として、レコード画像７４２Ａ～７４２Ｃは、それぞれ、モーション名７４３Ａ～７４３Ｃ、モーション画像７４４Ａ～７４４Ｃ、および、ＵＩ画像７４５Ａ～７４５Ｃを含む。以降、レコード画像７４２Ａ～７４２Ｃ、モーション名７４３Ａ～７４３Ｃ、モーション画像７４４Ａ～７４４Ｃ、および、ＵＩ画像７４５Ａ～７４５Ｃについて、区別する必要が無い場合、それぞれ、「レコード画像７４３２」、「モーション名７４３」、「モーション画像７４４」、「ＵＩ画像７４５」と記載する。

モーション名７４３は、モーションリスト４２２に格納されているモーションを識別する情報である。モーション画像７４４は、モーションリスト４２２において、各モーション名に対応付けられているモーションデータから生成される画像である。プロセッサ４０は、一例として、各モーションデータにおける最初の姿勢をとるアバターオブジェクト６１０の画像を、モーション画像７４４とてレコード画像７４２に含める。モーション画像７４４は、プレイヤによる所定の操作（例えば、モーション画像７４４に対するタップ操作）を受け付けるＵＩ画像であってもよい。プロセッサ４０は、該所定の操作を受け付けた場合、モーションデータに基づいてアバターオブジェクト６１０が動作するモーション動画を再生してもよい。プロセッサ４０は、モーション動画が終了すると、自動的にモーションリスト画面７４１を再表示してもよい。

なお、レコード画像７４２は、モーション画像７４４に代えて、例えば、「モーション再生」とのテキストを含むＵＩ画像を含んでもよい。

ステップＳ６６において、プロセッサ４０は、操作受付部４１３として、モーションを選択する第３操作を受け付ける。第３操作は、一例として、ＵＩ画像７４５へのタップ操作であってもよい。つまり、ＵＩ画像７４５は、各レコード画像７４２に対応するモーションデータを選択する操作を受け付ける。第３操作を受け付けたことにより、プロセッサ４０は、モーション特定部４１５として、プレイヤが選択したモーションデータを特定する。

ステップＳ６７において、プロセッサ４０は、表示制御部４１２および音声受付部４１４として、アバターオブジェクト６１０が、選択されたモーションデータに基づき動作するモーション動画を再生しながら、プレイヤの音声入力を受け付ける。

図２０は、プレイヤ４による音声入力の一具体例を示す図である。図２０に示すように、プレイヤ４は、モーション動画８１０Ａを再生しながら、発話音声８２０Ａを入力している。この発話音声８２０Ａは、ユーザ名が「ＡＡＡＡＡ」であるユーザ３（以下、ユーザ３Ａ）宛の発話音声である。つまり、図２０の例において、プレイヤ４は、ステップＳ６４にて、ユーザ３Ａ（第１ユーザ）を選択し、該ユーザ３Ａ宛の動作指図データを作成している。なお、ユーザ３Ａが使用するユーザ端末１００は、ユーザ端末１００Ａであるとする。

発話音声８２０Ａは、ユーザ３Ａ宛の発話音声であるため、該ユーザ３Ａがアバターオブジェクト６１０（換言すれば、プレイヤ４）に対して行った支援の内容に基づく発話音声となっている。具体的には、ユーザ３Ａは、１０Ｆというステージでのボス戦において、マガジンを投入し、その投入されたマガジンの銃弾でアバターオブジェクト６１０がボスに勝利している。このため、発話音声８２０Ａは、「ボス戦でマガジンをプレゼントしてくれてありがとう！タイミングも完璧だったね！ＡＡＡＡＡさんのおかげでクリアできたよ！」という内容である。このように、発話音声は、ユーザ３がゲームにおいて行った支援の内容と、ユーザ３への感謝とを含むものであることが好ましい。

ある局面において、プレイヤ４は、音声入力を開始する前、すなわち、第３操作を配信端末４００へ入力する前に、ユーザ３宛の発話内容を作成する。別の局面において、ユーザ３宛の発話内容は、プロセッサ４０が自動生成してもよい。また、プロセッサ４０は、第２操作によって選択されたユーザ３に対応付けられたタグを、モーション動画８１０Ａに重畳して表示させてもよい。

プロセッサ４０は、受け付けた音声を音声データに変換する。ステップＳ６８において、プロセッサ４０は、動作指図データ生成部４１６として、該音声データと、選択されたモーションのモーションデータとを含む動作指図データを生成する。

ステップＳ６９において、プロセッサ４０は、通信制御部４１１として、生成した動作指図データを選択されたユーザ３（図２０の例ではユーザ３Ａ）のユーザ端末１００（第１コンピュータ）に配信する。図２１は、配信端末４００に表示される画面のさらなる別の具体例を示す図である。プロセッサ４０は、ステップＳ６８の実行後、表示制御部４１２として、配信画面を表示部４５２に表示させる。配信画面は、一例として、図２１（Ａ）に示す配信画面７５１であってもよい。配信画面７５１は、ＵＩ画像７５２、および、モーション画像７５３Ａを含む。また、配信画面７５１は、図２１（Ａ）に示すように、動作指図データの配信先のユーザを示す情報を含むものであってもよい。

ＵＩ画像７５２は、動作指図データを選択されたユーザ３へ配信するための操作を受け付ける。該操作は、例えば、ＵＩ画像７５２へのタップ操作であってもよい。モーション画像７５３Ａは、生成した動作指図データに基づく動画、すなわち、ユーザ３Ａ用に生成した動作指図データに基づく動画を再生するための操作を受け付けるＵＩ画像である。該操作は、例えば、モーション画像７５３Ａへのタップ操作であってもよい。なお、生成した動画を再生するための操作を受け付けるＵＩ画像は、モーション画像７５３Ａに限定されない。例えば、「動画再生」とのテキストを含むＵＩ画像であってもよい。プロセッサ４０は、動画が終了すると、自動的に配信画面７５１を再表示してもよい。

配信画面７５１は、音声入力の受け付けに戻るための操作を受け付けるＵＩ画像をさらに含むことが好ましい。該操作は、例えば、該ＵＩ画像へのタップ操作であってもよい。配信画面７５１が該ＵＩ画像を含むことにより、プレイヤ４は、例えば、発話する内容を間違えた場合など、音声入力に失敗した場合に、再度音声入力を行うことができる。なお、該ＵＩ画像は、モーションデータの選択に戻るための操作を受け付けるＵＩ画像であってもよい。

ＵＩ画像７５２に対するタップ操作を受け付けると、プロセッサ４０は、ユーザ３Ａを示す情報とともに、動作指図データをサーバ２００へ送信する。サーバ２００は、ユーザ３Ａを示す情報に基づいて、動作指図データの送信先のユーザ端末１００を特定し、該動作指図データを特定したユーザ端末１００（すなわち、ユーザ端末１００Ａ）へ送信する。

プロセッサ４０は、動作指図データの送信が終了した場合、一例として、図２１（Ｂ）に示す配信完了画面７６１を表示部４５２に表示させてもよい。配信完了画面７６１は、一例として、ＵＩ画像７６２および７６３を含む。また、配信完了画面７６１は、図２１（Ｂ）に示すように、動作指図データの送信が完了したことを示すテキストを含むものであってもよい。

ＵＩ画像７６２は、別のユーザ３宛の動作指図データの作成を開始するための操作を受け付ける。該操作は、例えば、ＵＩ画像７６２をタップする操作であってもよい。プロセッサ４０は、該タップ操作を受け付けると、ユーザリスト画面を、表示部４５２に再度表示させる。すなわち、該タップ操作を受け付けた場合、配信処理は、ステップＳ６３に戻る。このとき、プロセッサ４０は、配信端末４００に記憶したユーザリスト４２１に基づいて、ユーザリスト画面を生成し、表示部４５２に表示させてもよい。ＵＩ画像７６３は、アプリケーションを終了するための操作を受け付ける。該操作は、例えば、ＵＩ画像７６３をタップする操作であってもよい。該操作を受け付けると、配信処理は終了する。

図２０、図２１を参照して説明した例では、図２１（Ｃ）に示すように、配信端末４００は、ユーザ３Ａ（ユーザ名が「ＡＡＡＡＡ」のユーザ３）宛の動画の動作指図データを、ユーザ端末１００Ａのみに送信する。

図２２は、プレイヤ４による音声入力の他の具体例を示す図である。図２２に示すように、プレイヤ４は、モーション動画８１０Ｂを再生しながら、発話音声８２０Ｂを入力している。この発話音声８２０Ｂは、ユーザ名が「ＢＢＢＢＢ」であるユーザ３（以下、ユーザ３Ｂ）宛の発話音声である。つまり、図２２の例において、プレイヤ４は、ステップＳ６４にて、ユーザ３Ｂに対応するレコード画像７３２Ｂへのタップ操作を入力し、ユーザ３Ｂ宛の動作指図データを作成している。なお、ユーザ３Ｂが使用するユーザ端末１００は、ユーザ端末１００Ｂであるとする。

発話音声８２０Ｂは、ユーザ３Ｂ宛の発話音声であるため、該ユーザ３Ｂがアバターオブジェクト６１０（換言すれば、プレイヤ４）に対して行った支援の内容に基づく発話音声となっている。具体的には、ユーザ３Ｂは、３Ｆというステージのザコ敵との戦闘において、ユーザ「ＢＢＢＢＢ」が救急箱を投入し、その結果、アバターオブジェクト６１０の体力が０になる（ゲームオーバーになる）寸前で体力が回復している。このため、発話音声８２０Ｂは、「ＢＢＢＢＢさんがプレゼントしてくれた救急箱のおかげで、３Ｆでゲームオーバーにならずにすんだよ。本当にありがとう！」という内容である。

図２３は、配信端末４００に表示される画面のさらなる別の具体例を示す図である。図２３（Ａ）に示す配信画面７５１は、ＵＩ画像７５２、および、モーション画像７５３Ｂを含む。モーション画像７５３Ｂは、タップ操作を受け付けると、ユーザ３Ｂ用に生成した動作指図データに基づく動画を再生する。

ＵＩ画像７５２に対するタップ操作を受け付けると、プロセッサ４０は、ユーザ３Ｂを示す情報とともに、動作指図データをサーバ２００へ送信する。サーバ２００は、ユーザ３Ｂを示す情報に基づいて、動作指図データの送信先のユーザ端末１００を特定し、該動作指図データを特定したユーザ端末１００（すなわち、ユーザ端末１００Ｂ）へ送信する。

図２２、図２３を参照して説明した例では、図２３（Ｃ）に示すように、配信端末４００は、ユーザ３Ｂ（ユーザ名が「ＢＢＢＢＢ」のユーザ３）宛の動画の動作指図データを、ユーザ端末１００Ｂのみに送信する。

以上のように、動作指図データに含まれる音声データに基づく音声の内容は、ユーザ３が直近のゲームへの参加において、プレイヤ４に対して行った支援の内容に基づくものとなる。該支援の内容はユーザ３ごとに異なるため、音声の内容は、ユーザ３ごとに異なる内容となる。つまり、ゲームの終了後、ゲームに参加したユーザ３の少なくとも一部のユーザ端末１００には、それぞれ異なる内容の音声を含む動作指図データが送信される。

また、図２２の例におけるアバターオブジェクト６１０のモーションは、図２０の例におけるモーションと異なる。つまり、プレイヤ４は、ユーザ３Ｂ宛の動作指図データ生成において、ユーザ３Ａ宛の動作指図データ生成時と異なるモーションデータを選択している。具体的には、プレイヤ４は、ステップＳ６６において、レコード画像７４２Ｂに対応するモーションデータを選択する、ＵＩ画像７４５Ｂへのタップ操作を入力している。このように、プレイヤ４は、動作指図データに含まれるモーションデータを、ユーザ３毎に異ならせることができる。

そして、ユーザ３毎に異なる内容の音声データと、ユーザ３毎に選択されたモーションデータとを含む、ユーザ３毎の動作指図データは、各ユーザ３のユーザ端末１００のみに送信される。換言すれば、ユーザ端末１００毎にユニーク（一意）の動作指図データが、選択されたユーザ３のユーザ端末１００の各々に送信される。

図２４は、ゲームプレイ端末３００からユーザ端末１００へのゲーム進行情報の送信の概要を示す図である。ユーザ端末１００における動画再生のための動作指図データが、ユーザ端末１００毎にユニークである一方、図２４に示すように、ゲーム実行中に、ゲームに参加している全てのユーザ３のユーザ端末１００に送信されるゲーム進行情報は、各ユーザ端末１００の間で共通である。すなわち、ゲーム進行情報に含まれる動作指図データもまた、各ユーザ端末１００の間で共通である。このように、動画再生のための動作指図データと、ゲームを進行させるための動作指図データとは、ユーザ端末１００間での同異、および、送信先といった観点で異なるデータであると言える。

（ユーザ端末１００における動画再生処理）
図２５は、ユーザ端末１００で実行される動画再生処理の流れの一例を示すフローチャートである。

ステップＳ７１において、プロセッサ１０は、動画再生部１１７として、動作指図データを受信する。ステップＳ７２において、プロセッサ１０は、動画再生部１１７として、動作指図データの受信をユーザ３へ通知する。プロセッサ１０は、一例として、通知画像の表示部１５２への表示、スピーカ（不図示）からの通知音声の再生、ＬＥＤ（light-emitting diode）などで構成される点灯部（不図示）の点灯または点滅の少なくともいずれかにより、動作指図データの受信をユーザ３へ通知する。

ステップＳ７３において、プロセッサ１０は、操作受付部１１１として、動画を再生するための第１再生操作を受け付ける。第１再生操作は、一例として、通知画像をタップする操作であってもよい。ステップＳ７４において、プロセッサ１０は、動画再生部１１７として、動作指図データをレンダリングし、動画を再生する。プロセッサ１０は、一例として、本ゲームをプレイするためのアプリケーションを起動し、動画を再生してもよいし、該アプリケーションとは別の、動画再生用のアプリケーションを起動し、動画を再生してもよい。以降、該動画を、「ありがとう動画」と記載する。

図２６は、ありがとう動画の再生の一具体例を示す図である。具体的には、ユーザ３Ａのユーザ端末１００における、ありがとう動画の再生の一例を示す図である。該ユーザ端末１００において再生されたありがとう動画９１０Ａにおいて、アバターオブジェクト６１０は、或るモーションを実行しながら、音声９２０Ａを発話している。換言すれば、プロセッサ１０は、或るモーションを実行するアバターオブジェクト６１０を含むありがとう動画９１０Ａを再生しながら、音声９２０Ａをスピーカ（不図示）から出力させている。

ありがとう動画９１０Ａにおけるモーションは、ユーザ３Ａ宛の動作指図データの生成において、プレイヤ４が選択したモーションデータに基づくものであり、音声９２０Ａは、該動作指図データの生成において、プレイヤ４が入力した発話音声８２０Ａから生成された音声データに基づくものである。つまり、音声９２０Ａは、ユーザ３Ａがゲームにおいて行った支援の内容と、該支援に対する感謝とを含む音声である。このように、ユーザ３Ａは、第１再生操作の入力により、自身がゲームにおいて行った支援の内容と、該支援に対する感謝とを、アバターオブジェクト６１０が発話するありがとう動画を視聴することができる。

ユーザ端末１００は、一例として、ありがとう動画９１０Ａの再生が終了した後、少なくとも１つのＵＩ画像をタッチスクリーン１５に表示させてもよい。該ＵＩ画像は、例えば、ありがとう動画９１０Ａをもう一度再生するための操作を受け付けるＵＩ画像であってもよいし、別の画面に遷移するための操作を受け付けるＵＩ画像であってもよいし、アプリケーションを終了するための操作を受け付けるＵＩ画像であってもよい。

また、ユーザ端末１００は、一例として、ありがとう動画９１０Ａの再生中に、少なくとも１つのＵＩ画像をタッチスクリーン１５に表示させてもよい。該ＵＩ画像は、例えば、再生中のありがとう動画９１０Ａを一時的に停止させたり、終了させたり、再生する場面を変更させたりする操作をそれぞれ受け付ける、複数のＵＩ画像であってもよい。

なお、ありがとう動画９１０Ａの再生中、および、ありがとう動画９１０Ａの再生が狩猟した後に表示されるこれらのＵＩ画像には、アバターオブジェクト６１０に対する返答を行うためのＵＩ画像は含まれない。すなわち、本実施形態に係るありがとう動画９１０Ａにおいては、アバターオブジェクト６１０に対する返答を行うための手段が備えられていない。

図２７は、ありがとう動画の再生の他の具体例を示す図である。具体的には、ユーザ３Ｂのユーザ端末１００における、ありがとう動画の再生の例を示す図である。該ユーザ端末１００において再生されたありがとう動画９１０Ｂにおいて、アバターオブジェクト６１０は、或るモーションを実行しながら、音声９２０Ｂを発話している。換言すれば、プロセッサ１０は、或るモーションを実行するアバターオブジェクト６１０を含むありがとう動画９１０Ｂを再生しながら、音声９２０Ｂをスピーカ（不図示）から出力させている。

ありがとう動画９１０Ｂにおけるモーションは、ユーザ３Ｂ宛の動作指図データの生成において、プレイヤ４が選択したモーションデータに基づくものであり、音声９２０Ｂは、該動作指図データの生成において、プレイヤ４が入力した発話音声８２０Ｂから生成された音声データに基づくものである。このため、図２７の例において、アバターオブジェクト６１０が行っているモーションは、図２６の例のモーションとは異なる。また、音声９２０Ｂは、ユーザ３Ｂがゲームにおいて行った支援の内容と、該支援に対する感謝とを含む音声である。このため、図２７の例において、音声９２０Ｂの内容は、図２６の例に
おける音声９２０Ａの内容とは異なる。

このように、ゲームの終了後に、ゲームに参加したユーザ３の少なくとも一部のユーザ端末１００が受信するありがとう動画は、ユーザ３毎にアバターオブジェクト６１０の発話内容が異なる動画である。

なお、プロセッサ１０は、次回のゲームへの参加を促す内容を含むＵＩ画像９３０を、動画９１０に重畳させて表示させてもよい。ＵＩ画像９３０は、動作指図データとともに配信されてもよいし、ゲーム情報１３２として、ユーザ端末１００が記憶していてもよい。

上記実施形態においては、演者の動きに応じてリアルタイムに動作するアバターオブジェクト６１０をゲームプレイ端末３００により規定される仮想空間６００Ａと同じ仮想空間６００Ｂ内において動作させ、仮想空間６００Ｂに配置されている仮想カメラ６２０Ｂの位置、向き、および傾きに応じた視界領域６４０Ｂの視界画像６６０をユーザ端末１００のタッチスクリーン１５に表示する例について説明した。このとき、仮想カメラ６２０Ｂの位置、向き等は、ユーザ端末１００のタッチスクリーン１５に対するスワイプ操作やピンチイン操作／ピンチアウト操作などに応じて変更する。しかし、仮想カメラ６２０Ｂの位置、向き等の変更は、これに限るものではない。

例えば、システム１の運営者または演者による図示しないスイッチャの操作に応じて位置、向き、および傾きを変化させるカメラオブジェクト６３０を仮想空間６００Ａに配置し（図２８（Ａ）参照）、当該カメラオブジェクト６３０の位置、向き等の変化に応じて仮想空間６００Ｂに配置されている仮想カメラ６２０Ｂの位置、向き等を変更するようにしてもよい。なお、カメラオブジェクト６３０は、演者が確認できるように、ゲームプレイ端末３００に接続されたＨＭＤ５００のモニタ５１にのみ表示される。この結果、演者は、カメラオブジェクト目線で発話等を行うことができる。

また、アバターオブジェクト６１０等を動作させる空間は、仮想空間に限らず、現実空間であってもよい。現実空間としては、例えば、カメラ（撮像部）１７により撮影されて取得した取得画像により特定される空間であってもよい。この場合、カメラ１７からの取得画像に対してアバターオブジェクト６１０等を配置してなる空間（以下、拡張現実空間ともいう）を生成するとともに、当該拡張現実空間に仮想カメラ６２０Ｂを配置し、例えばカメラ１７の位置、向きの変更等に応じて当該仮想カメラ６２０Ｂの位置、向き等を変更するようにしてもよい。

さらに、仮想カメラ６２０Ｂの位置、向き等の変更方法は、ユーザが選択可能となるようにしてもよい。例えば、ユーザ端末１００が選択可能な視聴モードとして複数種類の視聴モードを設け、ユーザ端末１００においてＴＶモード（第３視聴モード）が選択されているときは、運営者または演者によるスイッチャの操作に応じて位置、向き等が変化するカメラオブジェクト６３０に連動させて仮想カメラ６２０Ｂの位置、向き等を変更し、ユーザ端末１００において通常モード（第１視聴モード）が選択されているときは、ユーザによるスワイプ操作等に応じて仮想カメラ６２０Ｂの位置、向き等を変更し、ＡＲモード（第２視聴モード）が選択されているときは、カメラ１７からの取得画像に対してアバターオブジェクト６１０等を配置してなる空間（以下、拡張現実空間ともいう）を生成するとともに、当該拡張現実空間に仮想カメラ６２０Ｂを配置し、カメラ１７の位置、向き等の変更に応じて当該仮想カメラ６２０Ｂの位置、向き等を変更するようにしてもよい。これにより、タッチスクリーン１５に表示される画像の視点をユーザの好みに合わせて変更することができる。

以下においては、アバターオブジェクト６１０等が仮想空間６００Ｂまたは拡張現実空間内において動作し、仮想カメラ６２０Ｂの位置、向き等が変更される例について、視聴モード毎に説明する。具体的には、図２８～図３５を参照して、ユーザが、仮想空間６００Ｂまたは拡張現実空間内においてライブで動作するアバターオブジェクト６１０とジャンケンにより対決するゲーム（以下、ジャンケンゲームともいう）を行う例について説明する。

（通常モードおよびＴＶモード）
図２８（Ａ）は、ジャンケンゲームの進行に際して、ゲームプレイ端末３００側において規定される仮想空間６００Ａを模式的に説明するための図である。図２８（Ａ）では、仮想空間６００Ａ内においてアバターオブジェクト６１０と、選択肢オブジェクト２８１～２８３と、花輪を想起させる花輪オブジェクト２８４とが配置されている。アバターオブジェクト６１０は、ライブで演じているプレイヤ（演者）のモーションに応じて動き、当該演者による音声を発話する。アバターオブジェクト６１０の頭部の位置には、仮想カメラ６２０Ａが配置されている。また、仮想空間６００Ａには、図示していないが、その他のオブジェクトとして、アバターオブジェクト６１０の周囲を飾るオブジェクトや、視聴者に対応する視聴者オブジェクト、背景オブジェクト、床オブジェクトなどが配置されている。

また、選択肢オブジェクト２８１～２８３は、各々、棒部と、先端の円板部とから構成されている。円板部の面には、グー・チョキ・パーを表すイラストが描かれている。選択肢オブジェクト２８１～２８３は、各々、プレイヤによる掴むモーションに応じて、棒部を掴むことができる。プレイヤにより選択肢オブジェクト２８１～２８３等を掴む操作（モーション）は、プレイヤの手に取り付けられて当該手の動き（手の動作（例えば、各指の位置、握りの形状・向き等）を検出するモーションセンサ５２０が設けられるコントローラ５４０により検知される。プレイヤは、選択肢オブジェクト２８１～２８３のうち、最終的に出す手（グー・チョキ・パー）に対応する選択肢オブジェクトを掴んで上方に掲げることにより、アバターオブジェクト６１０が出す手が確定されることになる。

ゲームプレイ端末３００は、仮想空間６００Ａ内に配置されているオブジェクトのうち、少なくともアバターオブジェクト６１０および選択肢オブジェクト２８１～２８３の位置、姿勢、向きなどを特定するための情報（表示用データ）や音声データ（これらをまとめて動作指図データともいう）などを含むゲーム進行情報を、所定時間毎に複数のユーザ端末１００に向けてライブ配信する。複数のユーザ端末１００に向けて配信されるゲーム進行情報は、複数のユーザ端末１００間において共通の情報である。これにより、ゲームプレイ端末３００及び複数のユーザ端末１００各々の間で、少なくともアバターオブジェクト６１０および選択肢オブジェクト２８１～２８３の動作等を共有（同期）できる。ゲームプレイ端末３００及び複数のユーザ端末１００の間において共有するオブジェクトは、仮想空間６００Ａ内に配置されているオブジェクトのうち、少なくとも演者によりライブで演じられるアバターオブジェクト６１０を含むものであれば、アバターオブジェクト６１０のみでもよく、また、アバターオブジェクト６１０や選択肢オブジェクト２８１～２８３以外の他のオブジェクトを含むものであってもよい。また、ゲームプレイ端末３００から複数のユーザ端末１００に向けて配信されるデータには、ゲーム進行情報のみならず、初期配置情報や、ゲーム情報１３２、アバターオブジェクト６１０の出す手として確定した選択肢オブジェクトの種類（グー、チョキ、パー）を特定するための情報などが含まれる。また、当該データには、カメラオブジェクト６３０の位置、向き、傾き、即ち視点を特定可能な視点情報が含まれる。

ユーザ端末１００において規定された仮想空間６００Ｂには、仮想カメラ６２０Ｂが配置される。カメラオブジェクト６３０の視点は、運営者等によるスイッチャの操作に応じて変化し、ＴＶモードが選択されているユーザ端末１００においては、当該カメラオブジェクト６３０の視点情報に基づいて仮想カメラ６２０Ｂの位置、向き、傾きが変更される。

カメラオブジェクト６３０はＨＤＭ５００のモニタ５１に表示されるため、演者は、カメラオブジェクト６３０に目線を合わせることが可能となる。ＴＶモードが選択されているとき、仮想カメラ６２０Ｂは、アバターオブジェクト６１０を正面から視認し易い位置に自動で配置可能となり、表示部１５２に表示される映像は、アバターオブジェクト６１０を正面から見た映像になりやすくなる。

通常モードが選択されているユーザ端末１００においては、仮想カメラ６２０Ｂの位置、向き等は、当該視点情報ではなく、ユーザによる例えばスワイプ操作やピンチイン操作／ピンチアウト操作などに応じて変化する。例えば、左右方向へのスワイプ操作により仮想カメラ６２０Ｂの位置を左右に移動させ、上下方向へのスワイプ操作により仮想カメラ６２０Ｂの上下方向の向きを上下方向に変更させ、ピンチイン操作により仮想カメラ６２０Ｂの位置を仮想空間６００Ｂの外側に向けて移動（つまり縮小表示）させ、ピンチアウト操作により仮想カメラ６２０Ｂの位置を仮想空間６００Ｂの内側（あるいは、中心、アバターオブジェクト６１０）に向けて移動（つまり拡大表示）させる。また、これにより、仮想空間６００Ｂに配置されているオブジェクトをユーザが望む視点で視認することが可能となる。

（ＡＲモード）
図２８（Ｂ）は、ＡＲモードが選択されているユーザ端末１００側において規定され、取得画像に重畳させる拡張現実用の仮想空間６００Ｃ（以下、ＡＲ用仮想空間６００Ｃともいう）を模式的に説明するための図である。図２８（Ｂ）の例では、仮想空間６００Ａに配置されているオブジェクトのうち、アバターオブジェクト６１０および選択肢オブジェクト２８１～２８３のみが配置されている。ＡＲ用仮想空間６００Ｃには、少なくとも背景オブジェクトが配置されないものであればよく、例えば、アバターオブジェクト６１０および選択肢オブジェクト２８１～２８３に加えて、花輪オブジェクト２８４も配置されるものであってもよい。

当該ユーザ端末１００においては、カメラ１７により撮影されて取得した取得画像を解析することにより、床面等の平面部が特定される。ＡＲ用仮想空間６００Ｃ内の視界画像は、当該平面部の所定位置（例えば平面部の中心位置）に配置される。仮想カメラ６２０Ｂは、取得画像を撮影したときのカメラ１７の撮影方向と同じ方向からＡＲ用仮想空間６００Ｃを見る位置に配置される。この結果、カメラ１７からの取得画像に対して仮想カメラ６２０Ｂからの視界画像６４０Ｃを重畳させてなる拡張現実空間内の画像が表示部１５２に表示される。仮想カメラ６２０Ｂの位置、向き等は、カメラ１７の位置、向き等の変更に応じて変更される。取得画像は、カメラ１７の位置、向き等の変更に応じて変化し、視界画像６４０Ｃは、カメラ１７の位置、向き等と連動する仮想カメラ６２０Ｂの位置、向き等の変化に応じて変化する。

ＡＲモードが選択されているユーザ端末１００においては、カメラ１７から取得した取得画像に対してアバターオブジェクト６１０を含むオブジェクトを配置させてなる拡張現実空間内において、アバターオブジェクト６１０等が動作する。これにより、ユーザの目の前の現実空間においてアバターオブジェクト６１０等が実際に動作しているかのような印象（臨場感）をユーザに抱かせることができる。

（フローチャート）
図２９は、タッチスクリーン１５に対する入力操作等に基づいて視聴モードが切り替えられたときのユーザ端末１００の処理の流れの一例を示すフローチャートである。なお、視聴モードの切替えには、ＡＲモードのリセット（再起動）も含まれる。

ステップＳ８１において、ユーザ端末１００のプロセッサ１０は、視聴モードがＴＶモードまたは通常モードに切り替えられたか否かをタッチスクリーン１５に対する入力操作に基づいて判定する。ＴＶモードまたは通常モードに切り替えられたと判定されたときはステップＳ８２に進み、ＴＶモードまたは通常モードに切り替えられたと判定されなかったとき、つまりＡＲモードに切り替えられた、またはＡＲモードがリセットされたと判定されたときは、ステップＳ８８に進む。

ステップＳ８２において、プロセッサ１０は、図２８（Ａ）に示す仮想空間６００Ａと同じ仮想空間６００Ｂを規定する。ステップＳ８３において、プロセッサ１０は、仮想空間６００Ａに配置されている各種オブジェクトと同じオブジェクトを仮想空間６００Ｂに配置する。このとき、当該オブジェクトは、仮想空間６００Ａに配置されている各種オブジェクトと同じ位置関係となるように配置する。

ステップＳ８４において、プロセッサ１０は、視聴モードがＴＶモードに切り替えられたか否かを判定する。ＴＶモードに切り替えられたと判定されたときは、ステップＳ８５に進み、システム１の運営者等によるスイッチャの操作に応じてサーバ２００から送信される視点情報に基づいて、仮想カメラ６２０Ｂを仮想空間６００Ｂに配置する。この結果、仮想カメラ６２０Ｂの位置、向き等は、カメラオブジェクト６３０の位置、向き等と一致する。

ステップＳ８４においてＴＶモードに切り替えられたと判定されなかったときは、プロセッサ１０は、通常モードに切り替えられたとみなし、ステップＳ８６に進む。ステップＳ８６において、プロセッサ１０は、視聴モードが切り替えられる前に仮想カメラ６２０Ｂが配置されていた位置に対応する位置に、仮想カメラ６２０Ｂを配置する。具体的には、切替え前の視聴モードがＴＶモードであれば、仮想空間６００Ｂにおける仮想カメラ６２０Ｂの配置を維持する。一方、切替え前の視聴モードがＡＲモードであれば、ＡＲ用仮想空間６００Ｃにおいて仮想カメラ６２０Ｂが配置されていた位置を特定し、仮想空間６００Ｂのうち当該特定した位置と同じ位置に仮想カメラ６２０Ｂを配置する。これにより、通常モードに切り替えたときには、切り替え前の視点が維持可能となる。

ステップＳ８７において、プロセッサ１０は、視界画像６６０を表示部１５２に表示する。プロセッサ１０は、仮想カメラ６２０Ｂの位置と傾きとに応じて、仮想空間６００Ｂにおける仮想カメラ６２０Ｂからの視界である視界領域６４０Ｂを定義する。そして、プロセッサ１０は、視界領域６４０Ｂに対応する視界画像６６０を定義する。プロセッサ１０は、視界画像６６０を表示部１５２に出力することによって、視界画像６６０を表示部１５２に表示させる。ステップＳ８７の処理が完了すると、リターンする。

これに対してＡＲモードに切り替えられた場合、ステップＳ８８において、プロセッサ１０は、画像認識や空間認識に関する技術を用いて、カメラ１７により撮影されて取得した取得画像を解析する。これにより、例えば、取得画像から３次元空間が特定されるとともに、平面部（例えば水平部、具体的には床面）および当該平面部の大きさ（広さ）などが特定される。

次に、ステップＳ８９において、プロセッサ１０は、特定した平面部に基づいて、ＡＲ用仮想空間６００Ｃ内の視界画像を取得画像上に配置（重畳）する配置位置を設定する。プロセッサ１０は、平面部の所定位置（例えば平面部の中心位置）を、ＡＲ用仮想空間６００Ｃ内の視界画像を配置する位置として設定する。これにより、視界画像の配置位置が平面部の所定位置に紐付けられる。

ステップＳ９０において、プロセッサ１０は、図２８（Ｂ）に示すＡＲ用仮想空間６００Ｃを規定する。ステップＳ９１において、プロセッサ１０は、仮想空間６００Ａに配置されている各種オブジェクトのうちの一部のオブジェクトをＡＲ用仮想空間６００Ｃに配置する。図２８（Ｂ）の場合、当該一部のオブジェクトは、アバターオブジェクト６１０および選択肢オブジェクト２８１～２８３である。図２８（Ｂ）においては、アバターオブジェクト６１０および選択肢オブジェクト２８１～２８３が図２８（Ａ）と同じ位置関係となるように配置されている。なお、その他のオブジェクトとして花輪オブジェクト２８４が配置される場合においても、当該花輪オブジェクト２８４が図２８（Ａ）と同じ位置関係となるように配置される。

ステップＳ９２において、プロセッサ１０は、例えば、取得画像を撮影したときのカメラ１７の撮影方向（向き、傾き等）を特定し、当該撮影方向と同じ方向からＡＲ用仮想空間６００Ｃを見る位置に仮想カメラ６２０Ｂを配置する。具体的に、撮影方向が略水平方向であった場合にはＡＲ用仮想空間６００Ｃを水平方向から見る位置（例えば図３５（Ａ））に仮想カメラ６２０Ｂを配置し、撮影方向が斜め上方から見下ろす方向であった場合にはＡＲ用仮想空間６００Ｃを斜め上方から見下ろす位置に仮想カメラ６２０Ｂを配置する。

このように、ＡＲモードに切り替えられたときは、仮想カメラ６２０Ｂの位置は、モード切換え前の位置と異なり得る。この結果、ＡＲモードにおける視界画像も、ＴＶモードまたは通常モードにおける視界画像と異なり得る。この結果、ＡＲモードにおける視界画像を、ＴＶモードまたは通常モードに対して際立たせることが可能となる。

ステップＳ９３において、プロセッサ１０は、カメラ１７からの取得画像に対して仮想カメラ６２０Ｂからの視界画像６４０Ｃを重畳させてなる拡張現実空間内の画像を表示部１５２に表示させる。この際、プロセッサ１０は、視界画像６４０Ｃを、ステップＳ８９において設定された取得画像上の所定位置において、ステップＳ８８により特定した平面部の大きさに応じた表示サイズで重畳させて拡張現実空間内の画像を生成して表示する。ステップＳ９３の処理が完了すると、リターンする。

図３０は、視聴モードが切り替えられた後のユーザ端末１００の処理の流れの一例を示すフローチャートである。当該処理は、動作指図データを受信する毎や、所定時間毎等に実行される。

ステップＳ１０１において、プロセッサ１０は、動作指図データを受信する。ステップＳ１０２において、プロセッサ１０は、当該動作指図データに応じて、仮想空間６００Ｂまたは拡張現実空間でアバターオブジェクト６１０等を動かす。換言すれば、プロセッサ１０は、リアルタイムレンダリングにより、アバターオブジェクト６１０等が当該仮想空間６００Ｂまたは拡張現実空間内において動作している映像を再生する。

ステップＳ１０３において、プロセッサ１０は、ステップＳ８１の処理結果に基づいてＴＶモードが選択されているか否かを判定する。当該ＴＶモードが選択されていると判定されたときは、ステップＳ１０４に進み、システム１の運営者等によるスイッチャの操作に応じてサーバ２００から送信される視点情報に基づいて、仮想カメラ６２０Ｂを制御する。ステップＳ１０３においてＴＶモードが選択されていると判定されなかった場合、プロセッサ１０は、ステップＳ１０６に進み、ステップＳ８１の処理結果に基づいて通常モードが選択されているか否かを判定する。

当該通常モードが選択されていると判定されたときは、ステップＳ１０７に進み、ユーザからのスワイプ操作やピンチイン操作／ピンチアウト操作などの仮想カメラ６２０Ｂ（視点）を移動させるための移動操作を受け付けたか否かを判定する。ステップＳ１０７において移動操作を受け付けたと判定されていないときには、仮想カメラ６２０Ｂを移動させることなく、ステップＳ１０５に進む。

一方、ステップＳ１０７において移動操作を受け付けたと判定されたときには、ステップＳ１０８において、当該移動操作の態様に応じて仮想カメラ６２０Ｂ（視点）の移動先を特定する。具体的には、左右方向へのスワイプ操作の場合には、当該スワイプ操作の操作方向（左右、アバターオブジェクト６１０との距離はほぼ一定）への移動先を特定する。また、ピンチイン操作の場合には、当該ピンチイン操作の対象となる２点について縮められた距離に応じて仮想空間６００Ｂの外側（アバターオブジェクト６１０との距離が遠ざかる方向）への移動先を特定する。また、ピンチアウト操作の場合には、当該ピンチアウト操作の対象となる２点について広げられた距離に応じて仮想空間６００Ｂの内側（アバターオブジェクト６１０との距離が近づく方向）への移動先を特定する。仮想カメラ６２０Ｂ（視点）の移動距離は、例えば、スワイプ操作された距離や、ピンチイン操作により縮められた距離、ピンチアウト操作により広げられた距離などに比例する距離となる。なお、上下方向へのスワイプ操作の場合には、仮想カメラ６２０Ｂの向きを上下方向に変更させることができる。

ステップＳ１０９においては、特定された仮想カメラ６２０Ｂの移動先が予め定められている所定範囲内となるか否かを判定する。アバターオブジェクト６１０を演じる演者が実際に移動あるいは動作できる範囲は、例えば、演者が実際に存在する床面（あるいは、舞台、ステージ等）における所定位置から予め定められた範囲（例えば、半径２ｍ以内の範囲）内となるように予め定められている。所定位置は、床面等における略中央位置となる予め定められている位置などであってもよい。ステップＳ１０９における所定範囲は、演者が実際に移動あるいは動作できる範囲として予め定められている範囲に対応する仮想空間６００Ａ～６００Ｃにおける範囲である。換言すると、所定範囲は、演者が演じるアバターオブジェクト６１０が移動あるいは動作し得る範囲であって、アバターオブジェクト６１０が当該所定範囲外に出てしまうことが基本的に生じ得ない範囲ともいえる。ここで、図３１（Ａ）を参照して、仮想空間６００Ｂ内における所定範囲の具体例を説明する。

図３１（Ａ）は、通常モードにおける仮想空間６００Ｂを真上（天井、上方）から見下ろしたときの所定範囲６７０の一例を示している。図３１（Ａ）では、仮想空間６００Ｂの外縁を点線で示し、所定範囲６７０をグレーで示し、アバターオブジェクト６１０の位置を黒丸で示している。通常モード中における所定範囲６７０は、図３１（Ａ）に例示されるように、仮想空間６００Ｂ内の略中央において天井まで延びる円筒状（円柱状）の範囲であり、基本的に当該所定範囲６７０内においてアバターオブジェクト６１０が移動あるいは動作し得ることとなる。

ステップＳ１０９に戻り、特定された仮想カメラ６２０Ｂの移動先が所定範囲６７０内となると判定されなかったときには、ステップＳ１１０において、移動操作の態様に応じてステップＳ１０８にて特定されている移動先に仮想カメラ６２０Ｂを移動させる制御を行う。なお、本実施形態における仮想カメラ６２０Ｂの向きは、移動させる制御が行われたときにアバターオブジェクト６１０が配置されている方向に制御されるが、これに限らず、所定範囲内の予め定められた位置（例えば所定位置）の方向に制御されるものであってもよい。

図３１（Ｂ）は、通常モードにおける移動操作に応じて特定された仮想カメラ６２０Ｂの移動先が所定範囲６７０外となる場合の移動例を示している。図３１（Ｂ）では、仮想カメラ６２０Ｂの視点（図においては点で示す）が、位置ａにある状態においてピンチアウト操作が行われることにより、当該ピンチアウト操作に応じて位置ｂまで移動させる制御が行われる様子が示されている。このように、移動操作に応じて特定された仮想カメラ６２０Ｂの移動先が所定範囲６７０外となる場合には、当該特定された移動先に仮想カメラ６２０Ｂの視点を移動させることができる。

一方、ステップＳ１０９において特定された仮想カメラ６２０Ｂの移動先が所定範囲６７０内となると判定されたときには、当該所定範囲６７０内において移動あるいは動作し得るアバターオブジェクト６１０の内部に仮想カメラ６２０Ｂの視点が移動してしまう可能性があり、この場合、本来であればユーザに視聴させたくないアバターオブジェクト６１０の内部を表示してしまうなどといった不具合を生じさせてしまう虞がある。そこで、本実施形態の通常モード中において、ステップＳ１０９にて特定された仮想カメラ６２０Ｂの移動先が所定範囲内となると判定されたときには、所定範囲６７０内への移動を規制する制御が行われる。具体的には、ステップＳ１１１において、ステップＳ１０８にて特定されている移動先までの経路と所定範囲６７０の外縁（外周面）との交点に仮想カメラ６２０Ｂを移動させる制御を行う。

図３１（Ｃ）および図３１（Ｄ）は、通常モードにおける移動操作に応じて特定された仮想カメラ６２０Ｂの移動先が所定範囲６７０内となる場合の移動例を示している。図３１（Ｃ）では、仮想カメラ６２０Ｂの視点が位置ａにある状態においてピンチアウト操作が行われたことにより、当該ピンチアウト操作に応じてステップＳ１０９にて所定範囲６７０内となる位置ｃが移動先として特定された場合を例示している。この場合には、図３１（Ｄ）に示すように、ステップＳ１０８にて特定されている移動先である位置ｃまでの点線矢印で示される経路と、所定範囲６７０の外縁（外周面）との交点に仮想カメラ６２０Ｂを移動させる制御を行う。これにより、通常モードにおいては、仮想カメラ６２０Ｂを移動操作により比較的自由に移動させることを可能としつつも、移動操作に応じて特定された仮想カメラ６２０Ｂの移動先が所定範囲６７０内となる場合には、当該所定範囲６７０内への移動を規制して上記不具合を回避しつつも、所定範囲６７０外となる位置であって当該特定された移動先に最も近い位置まで仮想カメラ６２０Ｂを移動させることができる。

ステップＳ１０４、ステップＳ１１０、あるいはステップＳ１１１の処理が完了すると、ステップＳ１０５に進む。ステップＳ１０５において、プロセッサ１０は、仮想カメラ６２０Ｂの位置、向き等が変更されたことに応じて、視界画像６６０を更新する。これにより、ゲームプレイ端末３００側における仮想空間６００Ａ内におけるアバターオブジェクト６１０および選択肢オブジェクト２８１～２８３各々の動作と、ユーザ端末１００側における仮想空間６００Ｂ内におけるアバターオブジェクト６１０および選択肢オブジェクト２８１～２８３各々の動作とを同期させることができる。ステップＳ１０５の処理が完了すると、リターンする。

ステップＳ１０６において、通常モードが選択されていると判定されなかった場合、プロセッサ１０は、ＡＲモードが選択されているとみなして、ステップＳ１１２に進む。ステップＳ１１２において、プロセッサ１０は、ジャイロセンサやＧＰＳ信号等に基づいてカメラ１７の位置、向き、および傾き等を特定し、当該カメラ１７の位置、向き、および傾き等の変化に同期させて仮想カメラ６２０Ｂを制御する。

ステップＳ１１３においては、ステップＳ１１２において移動等された仮想カメラ６２０Ｂの位置がＡＲ用仮想空間６００Ｃ内に予め定められている所定範囲内となるか否かを判定する。ステップＳ１１３における所定範囲は、演者が実際に移動あるいは動作できるとして予め定められている範囲に対応するＡＲ用仮想空間６００Ｃにおける範囲であって、本実施形態では通常モード中のステップＳ１０９における所定範囲と同じ範囲に定められているものとする。ここで、図３２（Ａ）を参照して、ＡＲ用仮想空間６００Ｃ内における所定範囲の具体例を説明する。

図３２（Ａ）は、ＡＲモードにおけるＡＲ用仮想空間６００Ｃを真上（天井、上方）から見下ろしたときの所定範囲６８０の一例を示している。図３２（Ａ）では、仮想空間６００Ｃの外縁を点線で示し、所定範囲６８０をグレーで示し、アバターオブジェクト６１０の位置を黒丸で示している。ＡＲモード中における所定範囲６８０は、図３２（Ａ）に例示されるように、ＡＲ用仮想空間６００Ｃ内の略中央において天井まで延びる円筒状（円柱状）の範囲であり、基本的に当該所定範囲６８０内においてアバターオブジェクト６１０が移動あるいは動作し得ることとなる。

ステップＳ１１３に戻り、仮想カメラ６２０Ｂの位置が所定範囲６８０内となると判定されなかったときには、ステップＳ１１４において、プロセッサ１０は、取得画像および視界画像を更新する。これにより、カメラ１７の位置等の変化に応じて取得画像が変化するとともに、仮想カメラ６２０Ｂの位置等の変化に応じて視界画像が変化する。この結果、例えば、アバターオブジェクト６１０の左側面を撮影するかのようにカメラ１７を左側に旋回させたときには、カメラ１７により撮影されて取得される取得画像に対して、アバターオブジェクト６１０等を左側面から見た視界画像に更新される。

一方、ステップＳ１１３において仮想カメラ６２０Ｂの視点の位置が所定範囲６８０内となると判定されたときには、通常モード中と同様に、本来であればユーザに視聴させたくないアバターオブジェクト６１０の内部を表示してしまうなどといった不具合を生じさせてしまう虞がある。しかし、ＡＲモード中においては、カメラ１７の位置等の変化に応じて仮想カメラ６２０Ｂを移動させるモードであるため、通常モード中のように当該移動を規制した場合にはユーザに対して違和感を抱かせてしまう虞がある。そこで、本実施形態のＡＲモード中において、仮想カメラ６２０Ｂの位置が所定範囲６８０内であると判定されたときには、ステップＳ１１５においてＡＲ用仮想空間６００Ｃ内に配置されているアバターオブジェクト６１０を非表示とする設定を行い、ステップＳ１１４に移行する。この結果、アバターオブジェクト６１０にカメラ１７を近づけることにより所定範囲６８０内の視点からの画像を表示・視認可能となるが、アバターオブジェクト６１０が非表示となる。

図３２（Ｂ）および図３２（Ｃ）は、ＡＲモードにおける仮想カメラ６２０Ｂの位置が所定範囲６８０内となる場合の例を示している。図３２（Ｂ）では、仮想カメラ６２０Ｂの視点が位置ａにある状態において、ユーザ端末１００を所有するユーザが所定範囲６８０内に対応する位置まで移動することにより、仮想カメラ６２０Ｂの視点が所定範囲６８０内となる位置ｃまで移動した場合を例示している。この場合には、図３２（Ｃ）に示すように、仮想カメラ６２０Ｂの視点が位置ｃまで移動するものの、当該仮想カメラ６２０Ｂの視点位置が所定範囲６８０内に入ったときにアバターオブジェクト６１０が非表示となる。図３２（Ｃ）では、丸点線によりアバターオブジェクト６１０が非表示となっていることを示している。これにより、ＡＲモード中においては、カメラ１７の位置等の変化に応じて取得画像を変化させるとともに、仮想カメラ６２０Ｂの位置等の変化に応じて視界画像を変化可能としつつも、仮想カメラ６２０Ｂの位置が所定範囲６８０内となる場合にはアバターオブジェクト６１０を非表示とすることにより上記不具合を回避できる。

なお、仮想カメラ６２０Ｂの視点位置が所定範囲６８０内である間は、アバターオブジェクト６１０が非表示となるが、演者からの音声は継続して出力される。また、仮想カメラ６２０Ｂの視点位置が所定範囲６８０内から所定範囲６８０外となることにより、ステップＳ１１５の処理が行われず非表示が解除されるため、アバターオブジェクト６１０が表示可能な状態となる。

（表示例）
図３３～図３５は、ジャンケンゲーム進行中におけるユーザ端末１００の表示部１５２の表示例を示す図である。図３３～図３５は、同じ動作指図データを受信しているときの表示例を示している。具体的には、図３３は通常モードが設定されているときの表示例を示し、図３４はＴＶモードが設定されているときの表示例を示し、図３５はＡＲモードが設定されているときの表示例を示している。

（通常モードにおける表示例）
通常モードにおいて、プロセッサ１０は、ゲームプレイ端末３００における仮想空間６００Ａと同期する仮想空間６００Ｂを規定し、アバターオブジェクト６１０、選択肢オブジェクト２８１～２８３、花輪オブジェクト２８４、視聴者オブジェクト、背景オブジェクトなどのオブジェクトを当該仮想空間６００Ｂ内に配置する。また、プロセッサ１０は、当該仮想空間６００Ｂ内においてゲーム進行情報に基づいてアバターオブジェクト６１０等を動作させて、仮想カメラ６２０Ｂからの視界画像を表示部１５２に表示する。このため、表示部１５２には、アバターオブジェクト６１０の背後において花輪オブジェクト２８４が表示されるとともに、床オブジェクトや背景オブジェクトが表示される。

図３３（Ａ）におけるアバターオブジェクト６１０は、例えば「何を出そうかなー、どれにしようかなー」などと思案している様子（モーション）とともに音声が出力されているような場面を示している。また、ジャンケンゲーム進行中においては、各種のＵＩやゲーム情報等が表示部１５２に表示される。図３３（Ａ）においては、例えば、選択用ＵＩ１８０、ルール説明表示１８１、アイテム投入用アイコン１８５、コメント入力用アイコン１８６などが仮想空間６００Ｂ内の画像に重畳させて表示される。また、表示部１５２の左下には、アバターオブジェクト６１０に宛てて入力されたコメント内容を表示するためのコメント表示部１８４が設けられている。

ルール説明表示１８１は、ジャンケンゲームについてのルールを説明するための画像である。図３３（Ａ）では、例えば、「・全部で３回戦！」「・制限時間内にボタンを押そう！」「勝ち５０Ｐ」「あいこ１０Ｐ」「負け０Ｐ」といったメッセージ等が表示されている。

選択用ＵＩ１８０は、ユーザが出す手を選択するためのボタンアイコンを含み、当該ボタンアイコンへの入力操作（タップ操作）を受け付けるためのＵＩである。このため、図３３（Ａ）に示されるように、選択用ＵＩ１８０は、アバターオブジェクト６１０や、コメント表示部１８４、アイテム投入用アイコン１８５、コメント入力用アイコン１８６などよりも優先して表示される。図３３（Ａ）では、「出す手を選ぼう！」といったメッセージが表示されるとともに、その下方において左側からグーに対応するボタンアイコン、チョキに対応するボタンアイコン、パーに対応するボタンアイコンが表示されている。これにより、ユーザは、直感的にボタンアイコンに対するタッチ操作により出す手を選択できることを認識可能となる。また、「出す手を選ぼう！」のメッセージの左側には、出す手を選択できる制限時間（ここでは「１０」）が表示され、当該メッセージの右側には、当該選択用ＵＩ１８０自体の表示を消去するための「×」ボタンが表示されている。

ユーザは、出す手の選択を終えていなくても、「×」ボタンを選択することで選択用ＵＩ１８０を消去することができる。これは、選択用ＵＩ１８０が表示されていると、選択用ＵＩ１８０でアバターオブジェクト６１０（キャラクタ）や、コメント表示部１８４、アイテム投入用アイコン１８５などが隠れてしまい、ユーザからアバターオブジェクト６１０等の画像が見えにくくなってしまうためである。なお、選択用ＵＩ１８０を消去した結果、ユーザが制限時間内に出す手を選択しなかった場合、ユーザの出し手は自動的に決定されればよい。また、選択用ＵＩ１８０を消去している状態においては、再度選択用ＵＩ１８０を表示するためのアイコン（「ゲームに戻る」といったメッセージアイコン等）を表示し、当該アイコンへの入力操作により選択用ＵＩ１８０が再度表示されるようにしてもよいし、演者の指示により選択用ＵＩ１８０が再度表示されるようにしてもよいし、何らかの条件の成立（例えば、制限時間が特定の値になること）により、選択用ＵＩ１８０が再度表示されるようにしてもよい。

アイテム投入用アイコン１８５は、アイテムを投入してアバターオブジェクト６１０に付与する契機となるアイコンである。アイテム投入用アイコン１８５への入力操作が受け付けられたときには、複数種類のアイテムから選択して投入するためのウィンドウが表示される。前述したように選択用ＵＩ１８０は、アイテム投入用アイコン１８５よりも優先して表示される。このため、選択用ＵＩ１８０がアイテム投入用アイコン１８５に重畳して表示されているときには、当該選択用ＵＩ１８０の表示を消さなければ、アイテム投入用アイコン１８５への入力操作を有効に受け付けないようにしてもよい。

コメント入力用アイコン１８６は、アバターオブジェクト６１０に宛てにコメントを入力する契機となるアイコンである。コメント入力用アイコン１８６への入力操作が受け付けられたときには、コメントを入力して送信するためのウィンドウが表示される。なお、コメント入力用アイコン１８６については、選択用ＵＩ１８０が重畳して表示されることがない位置に表示されているが、アイテム投入用アイコン１８５と同様に、選択用ＵＩ１８０の表示を消さなければ、コメント入力用アイコン１８６への入力操作を有効に受け付けないようにしてもよい。コメント表示部１８４においては、アバターオブジェクト６１０宛てに入力されたコメントのうち新しいものから順に所定個数分のコメントがユーザ名とともに表示される。

図３３（Ｂ）は、ユーザが出す手を選択したときの表示例である。図３３（Ｂ）では、「グー」が選択された例を示す。「グー」が選択されると、図３３（Ｂ）に示されるように、選択用ＵＩ１８０内の「グー」のボタンアイコンが選択された状態（２重丸で囲われた状態）に更新される。なお、図３３（Ｂ）では、制限時間が「７」となっているため、ユーザは残り７秒を残して出す手を決定したことになる。これに対し、図３３（Ｂ）におけるアバターオブジェクト６１０については、選択肢オブジェクト２８１～２８３を掴んで、「どれにしようかなー、チョキかパーにしようかなー」などと思案している様子（モーション）とともに音声が出力されている場面が示されている。アバターオブジェクト６１０は、制限時間が経過した後に、演者のタイミングで「ジャンケンホイ」といった掛け声とともに、選択肢オブジェクト２８１～２８３のいずれか一つを上方に掲げる。

図３３（Ｃ）は、制限時間経過後においてアバターオブジェクト６１０の手を出したときの表示例である。図３３（Ｃ）では、アバターオブジェクト６１０により「チョキ」の選択肢オブジェクト２８２が掲げられている。これにより、アバターオブジェクト６１０が「チョキ」を出したことが報知される。アバターオブジェクト６１０が手を出したときには、アバターオブジェクト６１０の出す手として確定した選択肢オブジェクトの種類（グー、チョキ、パー）を特定するための情報を受信する。プロセッサ１０は、当該情報に基づいて、ユーザが出した手と比較してユーザの勝敗を判定する。図３３では、ユーザＡが「グー」を選択していたため、ユーザＡの勝ちと判定される。その結果、アバターオブジェクト６１０の上方において「勝ち」といったメッセージが表示される。

通常モードにおいて、仮想カメラ６２０Ｂの位置、向き等は、ユーザによるスワイプ操作やピンチイン操作／ピンチアウト操作などに応じて制御される。このため、左方向へのスワイプ操作が行われたときは、プロセッサ１０は、アバターオブジェクト６１０を中心として仮想カメラ６２０Ｂの位置を左方向に移動させる。また、右方向へのスワイプ操作が行われたときは、プロセッサ１０は、アバターオブジェクト６１０を中心として仮想カメラ６２０Ｂの位置を右方向に移動させる。また、上方向へのスワイプ操作が行われたときは、プロセッサ１０は、仮想カメラ６２０Ｂの向きを上方向に変化させる。また、下方向へのスワイプ操作が行われたときは、プロセッサ１０は、仮想カメラ６２０Ｂの向きを下方向に変化させる。

さらに、ピンチイン操作が行われたときは、プロセッサ１０は、仮想カメラ６２０Ｂの位置を仮想空間６００Ｂの外側に向けて移動させる。また、ピンチアウト操作が行われたときは、プロセッサ１０は、仮想カメラ６２０Ｂの位置を仮想空間６００Ｂの内側（あるいは、中心、アバターオブジェクト６１０）に向けて移動させる。これにより、ユーザの好みの視点で視界画像６６０を表示することが可能となる。

なお、図３３（Ｂ）のタイミングでは、図３３（Ａ）の状態と比較して、演者の動きに応じてアバターオブジェクト６１０が左側に向きを変化させている状態が示されており、図３３（Ｃ）のタイミングでは、図３３（Ａ）の状態と比較して、演者の動きに応じてアバターオブジェクト６１０が右側に向きを変化させている状態が示されている。このとき、ユーザは、アバターオブジェクト６１０を好みの視点から捉えるためにスワイプ操作を行い得る。図３３（Ｂ）のタイミングでは、左から右方向へのスワイプ操作により仮想カメラ６２０Ｂを左側に移動させたことにより、アバターオブジェクト６１０の右前部を捉えた表示例を示している。また、図３３（Ｃ）のタイミングでは、右から左方向へのスワイプ操作により仮想カメラ６２０Ｂを右側に移動させたことにより、アバターオブジェクト６１０の左前部を捉えた表示例を示している。

図３３（Ｄ）は、図３３（Ａ）の表示状態においてアバターオブジェクト６１０の胸元を原点としてピンチアウト操作が行われたときの表示例である。図３３（Ｄ）に示すように、ピンチアウト操作の原点となったアバターオブジェクト６１０の胸元を中心として、アバターオブジェクト６１０および花輪オブジェクト２８４などのオブジェクトが、当該ピンチアウト操作の動きに合わせて拡大表示される。逆に、図３３（Ｄ）の表示状態においてピンチイン操作が行われたときには、アバターオブジェクト６１０および花輪オブジェクト２８４などのオブジェクトが当該ピンチイン操作の動きに合わせて縮小表示される。なお、拡大表示や縮小表示された場合であっても、スワイプ操作に応じてその大きさを維持したまま（アバターオブジェクト６１０までの距離を維持したまま）仮想カメラ６２０Ｂを左右に移動させ上下に向きを変化させることができる。また、拡大表示や縮小表示された場合であっても、選択用ＵＩ１８０などのアイコン類については、図３３（Ｄ）に例示されるように、拡大／縮小されず、図３３（Ａ）と同じ状態で表示されるため、ユーザは、アイコンへの操作やコメントの確認を行うことができる。

図３３（Ｅ）は、図３３（Ｄ）の表示状態において、さらにピンチアウト操作が行われてステップＳ１０８で特定される仮想カメラ６２０Ｂの移動先が所定範囲６７０内となったときの表示例である。移動先が所定範囲６７０内となる場合には、前述したように、ステップＳ１０８にて特定されている移動先までの経路と、所定範囲６７０の外縁（外周面）との交点に仮想カメラ６２０Ｂを移動させる制御が行われる。これにより、本来であればユーザに視聴させたくないアバターオブジェクト６１０の内部を表示してしまうなどといった不具合を回避しつつも、図３３（Ｅ）に示されるように、アバターオブジェクト６１０を間近から視聴可能となる。

（ＴＶモードにおける表示例）
図３４は、ＴＶモードが設定されているときの表示例であり、図３４（Ａ）～図３４（Ｃ）は、各々、図３３（Ａ）～図３３（Ｃ）と同じタイミングの表示例を示している。図３４（Ｂ）および図３４（Ｃ）から分かるように、アバターオブジェクト６１０は、図３３と同様に、図３４（Ａ）の状態と比較して、図３４（Ｂ）のタイミングで左側に向きを変えており、図３４（Ｃ）のタイミングで右側に向きを変えている。

サーバ２００は、システム１の運営者等によるスイッチャの操作に応じたカメラオブジェクト６３０の視点情報を複数のユーザ端末１００に配信する。ＴＶモードにおいて、仮想カメラ６２０Ｂの位置、向き等は、カメラオブジェクト６３０の位置、向き等と一致するように、当該視点情報に基づいて制御される。図３４（Ｂ）は、カメラオブジェクト６３０の配置が仮想空間６００Ａの正面よりも右側の位置に切り替えられ、これに伴ってアバターオブジェクト６１０がカメラオブジェクト６３０側に向きを変えたときの表示例である。また、図３４（Ｃ）は、カメラオブジェクト６３０の配置が仮想空間６００Ａの正面よりも左側の位置に切り替えられ、これに伴ってアバターオブジェクト６１０がカメラオブジェクト６３０側に向きを変えたときの表示例である。即ち、アバターオブジェクト６１０がカメラオブジェクト６３０の目線と一致するようにアバターオブジェクト６１０の向きが変更されると、タッチスクリーン１５には、アバターオブジェクト６１０を正面から見る視点で視界画像６６０が表示される。このため、ＴＶモードを選択すると、ユーザは、運営者等がベストと考える視点から見た画像を視認することが可能となる。また、本来であればユーザに視聴させたくないアバターオブジェクト６１０の内部を表示してしまうような位置に運営者等が視点を設定することもないため、ＴＶモード中においては所定範囲６７０等に基づく視点の移動規制や非表示制御などを行う必要がない。

（ＡＲモードにおける表示例）
図３５は、ＡＲモードが設定されているときの表示例であり、図３５（Ａ）～図３５（Ｃ）は、各々、図３３（Ａ）～図３３（Ｃ）や図３４（Ａ）～図３４（Ｃ）と同じタイミングの表示例を示している。図３５（Ｂ）は、図３３（Ｂ）を表示しているタイミングにおいてカメラ１７の位置（即ち、ユーザ端末１００の位置）をＡＲ用仮想空間６００Ｃの正面の位置からアバターオブジェクト６１０を中心に４０°程度右側に移動させたときの表示例である。図３５（Ｃ）は、図３３（Ｃ）を表示しているタイミングにおいてカメラ１７の位置をＡＲ用仮想空間６００Ｃの正面の位置からアバターオブジェクト６１０を中心にさらに５０°程度右側に移動させたときの表示例である。図３５（Ａ）～図３５（Ｃ）では、カメラ１７により撮影されて取得された取得画像（壁に絵が飾られるとともに机が置かれている部屋の画像）に対してアバターオブジェクト６１０、選択肢オブジェクト２８１～２８３、および花輪オブジェクト２８４等が配置されている拡張現実空間の画像が、タッチスクリーン１５に表示される。

具体的には、図３５（Ａ）は、例えば、仮想空間６００Ａ内のアバターオブジェクト６１０等が図２８（Ａ）において示す状態であるときの表示例を示している。取得画像は、水平方向から撮影された画像である。このため、仮想カメラ６２０Ｂは、水平方向からＡＲ用仮想空間６００Ｃを見る位置に配置される。その結果、図３５（Ａ）では、アバターオブジェクト６１０を正面視することとなる。図３５（Ａ）に示されるように、アバターオブジェクト６１０は、取得画像のうちの平面部である床の略中央位置において起立している状態で表示され、当該アバターオブジェクト６１０を基準として、当該アバターオブジェクト６１０の右前方（図２８（Ａ）と同じ位置関係）に選択肢オブジェクト２８１～２８３が配置され、アバターオブジェクト６１０の背後（図２８（Ａ）と同じ位置関係）に花輪オブジェクト２８４が配置されている。

ＡＲモードにおいて、仮想カメラ６２０Ｂの位置、向き等は、カメラ１７の位置・向き等の変更に応じて制御される。このため、カメラ１７の位置（即ち、ユーザ端末１００の位置）をＡＲ用仮想空間６００Ｃの正面の位置から４０°程度右側に変更したときは、プロセッサ１０は、仮想カメラ６２０Ｂの位置を４０°程度右側に変更する。また、カメラ１７の位置をＡＲ用仮想空間６００Ｃの正面の位置からさらに５０°程度右側に変更したときは、プロセッサ１０は、仮想カメラ６２０Ｂの位置をさらに５０°程度右側に変更する。この結果、仮想カメラ６２０Ｂの位置が４０°程度右側に変更されたときは、図３５（Ｂ）に示す表示例に切り替わり、仮想カメラ６２０Ｂの位置がさらに５０°（合計９０°）程度右側に変更されたときは、図３５（Ｃ）に示す表示例に切り替わる。

図３５（Ｄ）は、図３５（Ａ）の表示状態において所定範囲６８０の外縁間近となる位置（所定範囲６８０外となる位置）までカメラ１７を移動させたときの表示例である。アバターオブジェクト６１０および花輪オブジェクト２８４などのオブジェクトがカメラ１７の位置（移動）に合わせて拡大表示される。逆に、図３５（Ｄ）の表示状態においてカメラ１７をアバターオブジェクト６１０から遠ざかる方向に移動させたときには、アバターオブジェクト６１０および花輪オブジェクト２８４などのオブジェクトがカメラ１７の位置（移動）に合わせて縮小表示される。なお、拡大表示や縮小表示された場合であっても、選択用ＵＩ１８０などのアイコン類については、図３５（Ｄ）に例示されるように、拡大／縮小されず、図３５（Ａ）と同じ状態で表示されるため、ユーザは、アイコンへの操作やコメントの確認を行うことができる。

図３５（Ｅ）は、図３５（Ｄ）の表示状態において、カメラ１７をさらにアバターオブジェクト６１０に近づく方向に移動させて当該カメラ１７に対応する仮想カメラ６２０Ｂが所定範囲６８０内となったときの表示例である。仮想カメラ６２０Ｂが所定範囲６８０内となる場合には、前述したように、ステップＳ１１５にてＡＲ用仮想空間６００Ｃ内に配置されているアバターオブジェクト６１０を非表示とする制御が行われる。このため、図３５（Ｅ）で示すように、アバターオブジェクト６１０が非表示となり、その背後に配置されている花輪オブジェクト２８４のみが表示される。このように、ＡＲモードにおいては所定範囲６８０内であるか否かにかかわらずカメラ１７の位置に対応させて仮想カメラ６２０Ｂを移動させつつも、仮想カメラ６２０Ｂの位置が所定範囲６８０内となる場合にはアバターオブジェクト６１０を非表示とすることにより上記不具合を回避できる。

（モード切り替え）
ＡＲモード移行用アイコン１８２ａは、ＡＲモードに移行させるためのアイコンである。ＴＶモード移行用アイコン１８２ｂは、ＴＶモードに移行させるためのアイコンである。通常モードにおいては、ＡＲモード移行用アイコン１８２ａとＴＶモード移行用アイコン１８２ｂとが、視界画像６６０の右上に重畳させて通常態様で表示される（図３３参照）。このため、ＴＶモード移行用アイコン１８２ｂに対するタッチ操作等が検出されることにより、視聴モードを通常モードからＴＶモードに切り替えることができる。また、ＡＲモード移行用アイコン１８２ａに対するタッチ操作等が検出されることにより、視聴モードを通常モードからＡＲモードに切り替えることができる。

ＴＶモードにおいては、ＡＲモード移行用アイコン１８２ａが通常モードと同じ位置に通常態様で表示され、ＴＶモード移行用アイコン１８２ｂが通常モードと同じ位置において強調態様で表示（例えば、白黒反転表示）される（図３４参照）。当該強調態様での表示により、ＴＶモード中である旨が報知される。ＡＲモード移行用アイコン１８２ａをタップすれば、視聴モードは、ＴＶモードからＡＲモードに切り替えられる。一方、強調態様で表示されているＴＶモード移行用アイコン１８２ｂをタップすれば、視聴モードは、ＴＶモードから通常モードに切り替えられる。また、ＴＶモードにおいては、ＡＲモード移行用アイコン１８２ａやＴＶモード移行用アイコン１８２ｂが表示されている領域以外の領域に対して、例えばスライド操作、スワイプ操作、ピンチイン／ピンチアウト操作等を行うことによっても、視聴モードがＴＶモードから通常モードに切り替えられる。

ＡＲモードにおいては、ＡＲモード移行用アイコン１８２ａが、拡張現実空間の画像の右上位置（通常モードと同じ位置）に強調態様で表示（例えば、白黒反転表示）され、ＡＲモード移行用アイコン１８２ａの下側におけるＴＶモード移行用アイコン１８２ｂに替えてＡＲモードリセット用アイコン１８２ｃが通常態様で表示される（図３５参照）。ＡＲモード移行用アイコン１８２ａの強調態様での表示により、ＡＲモード中である旨が報知され、ＡＲモードリセット用アイコン１８２ｃの通常態様での表示により、ＡＲモードをリセットできることが報知される。強調態様で表示されているＡＲモード移行用アイコン１８２ａをタップすれば、視聴モードは、ＡＲモードから通常モードに切り替えられる。一方、ＡＲモードリセット用アイコン１８２ｃをタップすれば、床面等の平面部が再度特定され、当該平面部の所定位置にＡＲ用仮想空間６００Ｃ内の視界画像が配置される。

即ち、本実形態においては、通常モードでは、当該通常モードと異なる視聴モードに対応するアイコンが表示される。アイコンがタッチされると、当該アイコンに対応する視聴モードに移行するとともに、当該アイコンが強調態様で表示される。移行先の視聴モードにおいて強調態様で表示されているアイコンがタッチされると、通常モードに戻る。また、移行先の視聴モードにおいて通常態様で表示されているアイコンがタッチされると、当該アイコンに対応するモードに移行する。これにより、ユーザは、選択中の視聴モードがどのモードであるかを認識しつつ、視聴モードを切り替えることが可能となる。

ＴＶモードに切り替えられると、サーバ２００から送信される視点情報に基づいて、仮想カメラ６２０Ｂが仮想空間６００Ｂに配置される。この結果、仮想カメラ６２０Ｂの位置、向き等は、カメラオブジェクト６３０の位置、向き等と一致する。

ＡＲモードに切り替えられると、取得画像を撮影したときのカメラ１７の撮影方向（向き、傾き等）が特定され、当該撮影方向と同じ方向からＡＲ用仮想空間６００Ｃを見る位置に仮想カメラ６２０Ｂが配置される。具体的に、撮影方向が略水平方向であった場合には、ＡＲ用仮想空間６００Ｃを水平方向から見る位置に仮想カメラ６２０Ｂが配置される。一方、撮影方向が斜め上方から見下ろす方向であった場合には、ＡＲ用仮想空間６００Ｃを斜め上方から見下ろす位置に仮想カメラ６２０Ｂが配置される。

通常モードに切り替えられると、モード切替え前に仮想カメラ６２０Ｂが配置されていた位置に対応する位置に、仮想カメラ６２０Ｂが配置される。具体的には、切替え前の視聴モードがＴＶモードであれば、仮想空間６００Ｂにおける仮想カメラ６２０Ｂの配置が維持される。一方、切替え前の視聴モードがＡＲモードであれば、ＡＲ用仮想空間６００Ｃにおいて仮想カメラ６２０Ｂが配置されていた位置が特定され、仮想空間６００Ｂのうち当該特定した位置と同じ位置に仮想カメラ６２０Ｂが配置される。切替え前の視聴モードがＡＲモードであって、ＡＲ用仮想空間６００Ｃにおいて仮想カメラ６２０Ｂが配置されていた位置が所定範囲６７０内となる位置であった場合には、仮想カメラ６２０Ｂが配置されていた位置から所定範囲６７０外となる最も近い位置に仮想カメラ６２０Ｂが配置される。なお、これに限らず、切替え前の視聴モードがＡＲモードであって、ＡＲ用仮想空間６００Ｃにおいて仮想カメラ６２０Ｂが配置されていた位置が所定範囲６７０内となる位置であった場合には、例えば、ＡＲ用仮想空間６００Ｃにおいて仮想カメラ６２０Ｂが配置されていた位置と同じ位置に仮想カメラ６２０Ｂを配置する一方で、通常モードへの切り替え後から当該仮想カメラ６２０Ｂが所定範囲６７０外に移動するまでの間においては通常モード中であってもアバターオブジェクト６１０を非表示とし（その他のオブジェクトについては表示）、移動操作に応じて仮想カメラ６２０Ｂを所定範囲６７０外に移動させた後にアバターオブジェクト６１０を表示するようにしてもよい。

＜本実施形態の効果＞
本実施形態によれば、アバターオブジェクト６１０は、演者の動きに応じてリアルタイムに動作するキャラクタであり、サーバ２００から送信される動作指図データは、当該アバターオブジェクト６１０が配置されている仮想空間を表示するためのデータである。ユーザ端末１００においては、仮想カメラ６２０Ｂ（視点）を移動させるための態様が異なる複数種類の視聴モードのうちのいずれかが特定され、当該特定された視聴モードに応じた画像が表示部１５２に表示される。また、タッチスクリーン１５への移動操作に応じて視点を移動させる通常モードと、ユーザ端末１００（カメラ１７）自体を移動させる操作に応じて視点を移動させるＡＲモードとを設け、通常モードにおいてはアバターオブジェクト６１０が配置され得る所定範囲６７０内への視点の移動を規制し、ＡＲモードにおいては所定範囲６８０内への視点の移動を許容するが当該所定範囲６８０内に視点を移動させたときにはアバターオブジェクト６１０を非表示とする。これにより、視聴モードに応じて視点を移動させることが可能となり、興趣が向上する。また、本来であればユーザに視聴させたくないアバターオブジェクト６１０の内部を表示してしまうなどといった不具合を回避できる。

また、ＡＲモードは、ユーザ端末１００（カメラ１７）の位置の変化に応じて仮想カメラ６２０Ｂを移動させるモードであるため、通常モードと同様に移動を規制した場合にはユーザに対して違和感を抱かせてしまうところ、所定範囲６８０内への移動を可能としつつ所定範囲６８０内に視点を移動させたときにはアバターオブジェクト６１０を非表示とする。これにより、ＡＲモード中においても違和感を低減させつつ、上記不具合を回避できる。

また、ＡＲモードでは、カメラ１７により取得された取得画像に対してアバターオブジェクト６１０等が配置されている拡張現実空間内の画像を表示する。これにより、ユーザの目の前の現実空間においてアバターオブジェクト６１０等が実際に動作しているかのような印象（臨場感）をユーザに抱かせることができる。

また、仮想空間６００Ａに配置されているカメラオブジェクト６３０の視点と同じ視点から仮想空間６００Ｂ内の画像を表示するＴＶモードにも切替可能である。これにより、配信側のスイッチャがベストと考える視点から見た画像をユーザが視認可能となる。

また、所定範囲６７０、６８０は、演者が実際に存在する床面における所定位置から予め定められた範囲（例えば、半径２ｍ以内の範囲）に対応する仮想空間６００Ａ～６００Ｃにおける予め定められている範囲である。これにより、例えば所定範囲６７０等がアバターオブジェクト６１０の位置に応じて変動するものなどと比較して、処理負担を軽減できる。また、通常モードにおける所定範囲６７０と、ＡＲモードにおける所定範囲６８０とは同一の範囲に定められている。これにより、例えばモードに応じて範囲を異ならせるものなどと比較して、処理負担を軽減できるとともに演者を混乱させてしまうことを防止できる。

また、通常モードおよびＡＲモードは、いずれも、アバターオブジェクト６１０を含む配信画像を視聴する同一のユーザからの操作・動作等に応じて移動される視点からの画像を表示する。このため、仮想空間に配置されているオブジェクトをユーザが望む視点で視認することを可能としつつも、視聴モードに応じて異なる画像を表示することが可能となり、興趣が向上する。

さらに、本実施形態におけるＴＶモードでは、カメラオブジェクト６３０の視点と同じ視点が、サーバ２００から送信される視点情報に基づいて特定される。これにより、データ量が増大してしまうことを防止できる。

また、本実施形態によれば、動作指図データは、アバターオブジェクト６１０を演じる演者の入力したモーションデータを含む。通常モードにおいては、アバターオブジェクト６１０が配置されている仮想空間６００Ｂ内の画像が、ユーザの操作に応じた視点で表示される。ＡＲモードにおいては、カメラ１７により取得された取得画像に対してアバターオブジェクト６１０が配置されている拡張現実空間内の画像が表示される。ＴＶモードにおいては、アバターオブジェクト６１０が配置されている仮想空間６００Ｂ内の画像が、仮想空間６００Ａに配置されているカメラオブジェクト６３０の視点と同じ視点で表示される。これにより、同じモーションデータ（動作指図データ）を受信しているにもかかわらず、視聴モードに応じて異なる画像を表示することが可能となる。

さらに、本実施形態によれば、視聴モードを切り替えるためのアイコンがタッチスクリーン１５に表示される。このため、アイコンタップといった簡単な操作により、視聴モードを切り替えることが可能となる。

＜変形例＞
以上説明した実施形態の変形例などを以下に列挙する。

（１）上記実施形態においては、通常モードにおける所定範囲６７０およびＡＲモードにおける所定範囲６８０のいずれもが、所定位置から演者が移動可能な範囲として予め定められている範囲である例について説明した。しかし、通常モードにおける所定範囲６７０およびＡＲモードにおける所定範囲６８０は、予め定められている範囲に限らず、演者（アバターオブジェクト６１０でもある）の現在位置を基準とする範囲（例えば、現在位置から半径１ｍ以内の範囲）であってもよい。この場合、通常モードにおける所定範囲６７０およびＡＲモードにおける所定範囲６８０の位置は、演者の現在位置に応じて移動し得ることとなる。これにより、所定範囲を極力狭い範囲に抑えることができる。

また、上記実施形態においては、通常モードにおける所定範囲６７０と、ＡＲモードにおける所定範囲６８０とが、同一の範囲である例について説明した。しかし、これに限らず、通常モードにおける所定範囲６７０と、ＡＲモードにおける所定範囲６８０とが、異なる範囲に定められているものであってもよい。例えば、通常モードにおける所定範囲６７０は、ＡＲモードにおける所定範囲６８０よりも広い範囲に定められているものであってもよい。これにより、ＡＲモード中においては、より近い位置からアバターオブジェクト６１０を視認可能となり、興趣を向上させることができる。また、例えば、通常モードにおける所定範囲６７０を、所定位置から演者が移動可能な範囲として予め定められている範囲とし、ＡＲモードにおける所定範囲６８０を、演者の現在位置を基準とする範囲としてもよい。これにより、ＡＲモード中における所定範囲を極力狭くでき、より近い位置からアバターオブジェクト６１０を視認可能となる。ＡＲモードで視聴しようとする動機を高めることができる。

（２）上記実施形態においてアバターオブジェクト６１０が登場するコンテンツは、毎日あるいは所定曜日の所定時間において定期的に配信されるものであってもよい。また、アバターオブジェクト６１０には、衣服やアクセサリー等の装飾オブジェクト（テクスチャ画像）が関連付けられており、例えば、アバターオブジェクト６１０となるキャラクタの上半身や、下半身、手、足、首元、耳たぶ、目元等の各部位には、衣服やアクセサリー（ネックレス、イヤリング、眼鏡等）に相当する装飾オブジェクトが予め関連付けられている。このような前提において、配信者は、例えば、アバターオブジェクト６１０に関連付けられる特定のオブジェクト（例えば、イヤリング）の表示態様を配信毎に変更してもよい。これにより、視聴者であるユーザは、当該ユーザからの要求の有無にかかわらず特定のオブジェクトの表示態様が配信毎に異なるものに変化していることを体感でき、その結果、アバターオブジェクト６１０の実在感をユーザに抱かせることができる。また、ＡＲモードである場合には、アバターオブジェクト６１０に関連付けられる特定のオブジェクトを表示可能となる位置に視点を移動可能である一方、通常モードである場合には、アバターオブジェクト６１０に関連付けられる特定のオブジェクトを表示可能となる位置に視点を移動不可能となるようにしてもよい。図３６を用いてその一例を説明する。

図３６は、アバターオブジェクト６１０として帽子を着用した女性を模したキャラクタが仮想空間６００Ｂに登場する例を示す。アバターオブジェクト６１０には、キャラクタが全身に羽織るワンピース、頭部に被る帽子、耳に付けるピアスなどの装飾オブジェクトが関連付けられている。図３６では、アバターオブジェクト６１０に関連付けられている装飾オブジェクトのうちのピアスが、特定のオブジェクトに相当する。このため、当該ピアスの表示態様は、配信毎に異なる表示態様に設定される。

まず、図３６（Ａ）を参照して、通常モードについて説明する。図３６（Ａ－１）は、アバターオブジェクト６１０が正面を向いて右手の人差し指を前に掲げているときの表示例である。図３６（Ａ－２）は、キャラクタが右斜め前を向いて右手の人差し指で前方を指しているときの表示例である。当該通常モードでは、スワイプ操作・ピンチイン操作・ピンチアウト操作等に応じて仮想カメラ６２０Ｂの位置、向き、および傾きが変更される。ただし、ピアスは、他のオブジェクトに相当する帽子により覆われており、通常モード中においてどのようにスワイプ操作等を行ったとしても、ピアスが見える位置（例えば、後述する図３６（Ｂ－３）や図３６（Ｂ－４）などを表示可能とする位置）に仮想カメラ６２０Ｂ（視点）を移動させることはできない。例えば、通常モードにおける所定範囲６７０は、ピアス（特定部位）が見える位置をすべて含むように定められているものであってよい。

一方、ＡＲモードにおける所定範囲６８０は、ピアス（特定部位）が見える位置の少なくとも一部を含まないように定められているものであってよい。図３６（Ｂ）を参照して、ＡＲモードについて説明する。図３６（Ｂ－１）および図３６（Ｂ－２）は、各々、図３６（Ａ－１）および図３６（Ａ－２）と同じタイミングにおけるＡＲモード中の表示例を示している。当該ＡＲモードでは、カメラ１７により撮影されて取得された取得画像に対してアバターオブジェクト６１０が配置されている拡張現実空間の画像のうち、仮想カメラ６２０Ｂからの画像が、表示部１５２に表示される。また、仮想カメラ６２０Ｂの位置、向き、傾き等は、カメラ１７の実際の位置、向き、傾き等に応じて変更される。

このため、アバターオブジェクト６１０の左方の斜め下あたりから左耳を見上げるようにカメラ１７の位置・向き等を調整すれば、ピアスが見える位置に仮想カメラ６２０Ｂが移動し、ピアスの画像が表示部１５２に表示される（図３６（Ｂ）の（Ｂ－３）参照）。即ち、ピアスの表示態様は、ＡＲモードを選択し、カメラ１７の位置・向き等を調整することにより、確認することができる。これにより、ＡＲモードで視聴することに対するモチベーションをユーザに持たせることができ、ひいては好趣を向上させることができる。なお、キャラクタの足元から当該キャラクタの左半身を見上げるようにカメラ１７の位置・向き等を調整すれば、図３６（Ｂ）の（Ｂ－４）に示すように、足を含む左半身の画像が表示部１５２に表示される。アバターオブジェクト６１０に近づき過ぎて、仮想カメラ６２０Ｂ（視点）が所定範囲６８０内に入ったときには、アバターオブジェクト６１０が非表示となる。このため、所定範囲６８０内に入らないようにしつつ、どの位置・角度からであればピアスを捉えることができるのかといった面白味をユーザに提供できる。

このようにＡＲモードにおいては、カメラ１７の位置・向き等を調整することにより、アバターオブジェクト６１０に関連付けられるピアスを表示可能な位置（例えば、キャラクタの首元から見上げるような位置、キャラクタの足元から見上げるような位置など）に仮想カメラ６２０Ｂを移動させることができる。その結果、ピアスを表示させることができ、ユーザは当該ピアスの表示態様を確認できる。一方、通常モードにおいては、前述したように、どのように操作を行ったとしても、キャラクタに関連付けられるピアスを表示可能な位置（例えば、キャラクタの足元から見上げるような位置など）に仮想カメラ６２０Ｂを移動させることができない。その結果、特定のオブジェクトであるピアスを表示させることができず、ユーザは当該ピアスの表示態様を確認できない。

図３６では、アバターオブジェクト６１０に関連付けられている装飾オブジェクトのうちの特定のオブジェクトとしてピアスを例示し、当該ピアスの表示態様を変更する例について説明した。しかし、特定のオブジェクトは、アバターオブジェクト６１０に関連付けられているオブジェクトであれば、シャツやピアスに限らず、靴下、ズボン、髪留め、手袋、帽子、下着などのオブジェクトであってもよい。また、特定のオブジェクトは、装飾オブジェクトに限らず、例えば、キャラクタ自身にかかわるオブジェクト（例えば、髪型、ネイル等）であってもよい。

なお、通常モードおよびＡＲモード各々の所定範囲にかかわらず、ＡＲモードである場合には、アバターオブジェクト６１０に関連付けられる特定のオブジェクトを表示可能となる位置に視点を移動可能であり、通常モードである場合には、アバターオブジェクト６１０に関連付けられる特定のオブジェクトを表示可能となる位置に視点を移動不可能となるように、仮想カメラ６２０Ｂ（視点）の移動可能範囲を制御するようにしてもよい。また、この場合における特定のオブジェクトは、配信毎に表示態様が変更されるオブジェクトに限らず、表示態様が変更されず一律となるオブジェクトであってもよい。

また、ＡＲモード中において特定のオブジェクトが見える位置のうちの一部に該当する特定位置に仮想カメラ６２０Ｂ（視点）が移動した場合には、アバターオブジェクト６１０を非表示とするようにしてもよい。例えば、ＡＲモード中における所定範囲６８０に、特定位置を含めるようにしてもよい。

また、アバターオブジェクト６１０には、視聴モードにかかわらず仮想カメラ６２０Ｂの視点から捉えることができない部位が定められているものであってもよい。例えば、図３６に示すアバターオブジェクト６１０では、例えば、ピアスが付けられている左耳とは逆の右耳に対応する部位が帽子の鍔で隠れており、いずれの視聴モードであっても、仮想カメラ６２０Ｂの視点から捉えることができないように定められているものであってもよい。

（３）上記実施形態では、通常モードおよびＡＲモードにおける所定範囲として、円筒状となる範囲を例示したが、アバターオブジェクト６１０を含む形状の範囲であればこれに限らず、上方よりも下方の方が広くなるような形状（例えば、テーパー状）となる範囲であってもよく、アバターオブジェクト６１０そのものの形状となる範囲であってもよい。

（４）上記実施形態におけるＴＶモードでは、本来であればユーザに視聴させたくないアバターオブジェクト６１０の内部を表示してしまうような位置に運営者等が視点を設定することもないため、所定範囲６７０等に基づく視点の移動規制や非表示制御などを行わない例について説明したが、例えば、配信側の端末（例えば、配信端末４００、ゲームプレイ端末３００等）において、運営者が所定範囲６７０等に対応する範囲内に視点を誤って設定してしまった場合にその旨を運営者に対して報知する処理を行うようにしてもよく、また、運営者が所定範囲６７０等に対応する範囲内に視点が設定できないように規制するための処理を行うものであってもよい。

また、配信側の端末（例えば、配信端末４００、ゲームプレイ端末３００等）においては、演者が所定範囲６７０等に対応する予め定められた範囲から外に出たときや、当該予め定められた範囲までの距離が所定距離（例えば３０ｃｍ）以内となったときなどに、その旨を演者や運営者に対して報知する処理を行うようにしてもよい。

また、ユーザ端末１００側においては、アバターオブジェクト６１０が所定範囲外に出たときには、当該アバターオブジェクト６１０の位置を所定範囲内の所定位置となるように変更設定するための処理を行い、強制的に所定範囲内となる位置にアバターオブジェクト６１０を移動（横滑り表示）させるようにしてもよい。

（５）上記実施形態において通常モードにおいては、アバターオブジェクト６１０が配置され得る所定範囲６７０内への視点の移動を規制し、ＡＲモードにおいては、所定範囲６８０内への視点の移動を許容するが当該所定範囲６８０内に視点を移動させたときにはアバターオブジェクト６１０を非表示とする例について説明した。しかし、ＡＲモードにおいては、アバターオブジェクト６１０が配置され得る所定範囲６７０内への視点の移動を規制し、通常モードにおいては、所定範囲６８０内への視点の移動を許容するが当該所定範囲６８０内に視点を移動させたときにはアバターオブジェクト６１０を非表示とするものであってもよい。

（６）上記実施形態においては、アバターオブジェクト６１０に対応して所定範囲を設け、通常モードにおいては所定範囲内への仮想カメラ６２０Ｂ（視点）の移動を規制し、ＡＲモードにおいては所定範囲内への移動を許容する一方でアバターオブジェクト６１０を非表示とする例について説明した。しかし、このような制御が行われるオブジェクトは、演者が演じるアバターオブジェクト６１０に限らず、他のオブジェクトに適用するものであってもよい。また、演者が演じるアバターオブジェクト６１０以外のオブジェクト（例えば、花輪オブジェクト２８４等）については、当該オブジェクト各々に対応して所定範囲が設けられており、視聴モードにかかわらず、当該所定範囲内への仮想カメラ６２０Ｂ（視点）の移動が許容される一方で、仮想カメラ６２０Ｂ（視点）が入った所定範囲に対応するオブジェクトを非表示とするようにしてもよい。あるいは、演者が演じるアバターオブジェクト６１０以外のオブジェクト（例えば、花輪オブジェクト２８４等）については、視聴モードにかかわらず、所定範囲内への仮想カメラ６２０Ｂ（視点）の移動を規制するようにしてもよい。

（７）上記実施形態においては、ＡＲモードにおいて、アバターオブジェクト６１０や選択肢オブジェクト２８１～２８３をカメラ１７から取得された取得画像に配置する例について説明した。しかし、ＡＲモードにおいては、取得画像に対して配置するアバターオブジェクト６１０や選択肢オブジェクト２８１～２８３のサイズをユーザ操作に応じて調整可能とするようにしてもよい。

アバターオブジェクト６１０や選択肢オブジェクト２８１～２８３を含む視界画像が配置される際の表示サイズは、取得画像を解析することにより特定された平面部の大きさに応じて決定されるため、解析結果によっては、取得画像に対してアバターオブジェクト６１０等が極端に大きく表示されてしまう場合や逆に小さく表示されてしまう場合が生じ得る。このような場合に、ユーザ操作を受け付けることにより、アバターオブジェクト６１０等の表示サイズを取得画像に対して適正な表示サイズあるいはユーザの好みの表示サイズに調整することで、アバターオブジェクト６１０等の表示に対して違和感を抱かせてしまうという不都合を回避できる。

（８）上記実施形態においては、拡張現実空間が、カメラ１７からの取得画像に対して仮想空間６００Ａにおける一部のオブジェクトのみを配置させた空間である例について説明した。しかし、カメラ１７からの取得画像に対して配置するオブジェクトは、プレイヤが演じるアバターオブジェクト６１０を含むものであればこれに限らず、仮想空間６００Ａに配置されているすべてのオブジェクトとしてもよい。つまり、拡張現実空間は、カメラ１７からの取得画像に対して仮想空間６００Ａと同じ仮想空間全体を配置させてなる空間であってもよい。具体的には、カメラ１７からの取得画像に対して、前述の仮想空間６００Ａ全体をミニチュア化して配置させてなる拡張現実空間を生成し、当該拡張現実空間内においてアバターオブジェクト６１０等を動作させるようにしてもよい。

（９）上記実施形態においては、ユーザの操作に応じて視聴モードを切り替えるようにしている。しかし、コンテンツの種類や時間帯に応じて運営者側において視聴モードが特定されて、当該視聴モードを特定可能なモード情報を、ゲームプレイ端末３００から複数のユーザ端末１００に向けて配信されるデータに含め、ユーザ端末１００は、当該モード情報に基づく視聴モードで配信コンテンツを視聴できるようにしてもよい。また、運営者がＴＶモードへの切替えを要求する情報を配信できるようにし、当該情報が配信されている期間は視聴モードをＴＶモードに設定するようにしてもよい。これにより、例えばアバターオブジェクト６１０が着替え等を行う期間に、カメラオブジェクト６３０の向きをアバターオブジェクト６１０を撮影できない方向に変更し、当該着替えのシーンがユーザ端末１００に表示される不都合を回避することができる。なお、当該情報が配信されている期間においても、プレミアムユーザなどの特定のユーザについては、視聴モードの切替えを許可するようにしてもよい。

（１０）上記実施形態において拡張現実空間を構成する取得画像は、カメラ１７によりリアルタイムで撮影された画像である例について説明した。しかし、拡張現実空間を構成する取得画像は、リアルタイムで撮影された画像に限らず、過去に撮影した画像であってもよい。また、拡張現実空間を構成する取得画像は、現実空間の様々な場所で撮影された画像（パノラマ画像等を含む）を提供するサービス提供装置（サーバ）から提供される画像であってもよい。この場合において提供される画像は、例えば、ユーザ端末１００が存在する位置の画像であってもよく、また、マップ上を移動するいわゆる位置ゲームを行っているときには当該マップに対してユーザが指定した位置の画像であってもよい。

また、拡張現実空間の生成においては、取得した取得画像をそのまま用いて、その上にキャラクタ等を重畳させてタッチスクリーン１５に表示する例について説明した。しかし、拡張現実空間の生成に用いる取得画像については、所定の加工・編集処理を行い、当該加工・編集処理が施された画像にキャラクタ等を重畳させてタッチスクリーン１５に表示するようにしてもよい。所定の加工・編集処理は、例えば、入力操作に応じて拡大・縮小等を行うものであってもよく、また、現在の状況（例えば、時期、日付、時間等）に応じて、グラデーション、シャープネス、色補正、特殊効果等を行うようにしてもよい。

上記実施形態においては、仮想空間６００Ａの一部のオブジェクトを取得画像上に配置させてなる拡張現実空間内の画像を表示する手法として、図２８（Ｂ）および図３５を参照して一例を示した。しかし、このような拡張現実空間内の画像を表示する手法としては、カメラ１７により取得した取得画像に対してアバターオブジェクト６１０等を配置させて動作させるものであればよく、その他の手法を用いるものであってもよい。例えば、ＡＲ用仮想空間６００Ｃ内において仮想空間６００Ａと同じようにすべてのオブジェクト（視聴者オブジェクトや、床オブジェクト、背景オブジェクト等）を配置させた上で、アバターオブジェクト６１０および選択肢オブジェクト２８１～２８３以外のその他のオブジェクト（視聴者オブジェクトや装飾オブジェクト）の表示設定を非表示設定とし、仮想カメラ６２０Ｂからの視界画像としてアバターオブジェクト６１０および選択肢オブジェクト２８１～２８３のみが含まれ、その他のオブジェクトが含まれないようにし、当該視界画像をカメラ１７からの取得画像に対して重畳させることにより拡張現実空間内の画像を生成するようにしてもよい。この場合において強調表示されているＡＲモード移行用アイコン１８２ａへの入力操作が受け付けられたときには、ＡＲ用仮想空間６００Ｃ内において配置されているが非表示設定となっているオブジェクト（視聴者オブジェクトや、床オブジェクト、背景オブジェクト等）について、表示される設定に切り替えることにより、拡張現実空間ではなく仮想空間６００Ａと同じ仮想空間内においてアバターオブジェクト６１０等を動作させるようにしてもよい。これにより、通常モード移行時等における処理を簡易化できるとともに処理負担を軽減できる。

（１１）上記実施形態におけるアバターオブジェクト６１０の表示態様は、例えば、拡張現実空間の生成に用いる取得画像の種類（例えば、部屋の画像、ショッピングモールの画像、風景画像）に応じてユーザ毎に異なり得るようにしてもよい。例えば、ゲームプレイ端末３００側から送信されるゲーム進行情報が同じであっても、取得画像が部屋の画像であるユーザ端末については、アバターオブジェクト６１０の衣装をパジャマとしてもよく、取得画像が山の画像であるユーザ端末については、アバターオブジェクト６１０の衣装を登山服としてもよい。この場合、アバターオブジェクト６１０の衣装データは、各ユーザ端末１００側において予め複数種類記憶されているようにしてもよい。なお、アバターオブジェクト６１０の表示態様を異ならせる対象は、衣装に限らず、髪型、肌の色、化粧の程度等であってもよい。これにより、ゲーム進行情報を出力するゲームプレイ端末３００側の処理負担を増大させることなく、拡張現実空間のバリエーションを増やすことができる（取得画像次第で実質無限となる）ため、ユーザを惹きつけることが可能となる。

これに替えてあるいは加えて、アバターオブジェクト６１０の表示態様は、ゲーム中においてユーザによる課金に応じて、他のユーザのユーザ端末において表示される表示態様と異ならせることができるようにしてもよい。また、アバターオブジェクト６１０の表示態様は、ライブゲーム等の結果に応じて更新されるユーザのランキングに応じて異なるようにしてもよい。

（１２）上記実施形態において図２９のステップＳ９２においては、取得画像を撮影したときのカメラ１７の撮影方向（向き、傾き等）に基づき、当該撮影方向と同じ方向となるように仮想カメラ６２０Ｂを配置する例について説明した。しかし、仮想カメラ６２０Ｂを初期配置する位置・向き等については、これに限らず、コンテンツの種類に応じて設定されるものや、ステップＳ８８における解析結果に基づいて設定されるもの、予め定められている位置・向き等に設定されるものなどであってもよい。

また、ステップＳ９２において仮想カメラ６２０Ｂが初期配置された後においては、図３０のステップＳ１１２において示したように、カメラ１７の位置、向き、および傾き等の変化に同期させて仮想カメラ６２０Ｂを制御する例について説明した。しかし、初期配置後の仮想カメラ６２０Ｂは、ユーザからの入力操作（例えば、スワイプ操作、タッチ操作等）に応じて、位置、向き、および傾き等を制御するようにしてもよい。これにより、ユーザからの入力操作に応じて、仮想カメラ６２０Ｂの視界領域を変更でき、その結果、取得画像上に配置される視界画像を変更できる。具体的には、スワイプ操作により、取得画像上に配置されるアバターオブジェクト等（例えば、アバターオブジェクト６１０のみ、アバターオブジェクト６１０およびその他のオブジェクト、仮想空間全体）を回転させたり、移動させたりできるようにしてもよい。これにより、例えば、ユーザ端末１００の位置や向き等を十分に調整できないような狭いスペースにおいて拡張現実空間を生成してアバターオブジェクト６１０等を動作させているときであっても、タッチスクリーン１５に対する入力操作により当該アバターオブジェクト６１０等を回転・移動させることが可能となる。

（１３）上記実施形態においては、仮想空間６００Ｂまたは拡張現実空間内において進行するコンテンツとして、図３３～図３５に示すジャンケンゲームなどのプレイヤとユーザとが対戦するライブゲームを例示した。しかし、仮想空間６００Ｂまたは拡張現実空間内において進行するライブゲームは、これに限らず、プレイヤとユーザとが交替でパチンコを操作し、前方に配置されているトレーを模したオブジェクト上に、当該パチンコで飛ばした果物を模したオブジェクトをどれだけ載せられるか（どちらが失敗せずに載せられるか）を競うパズルゲームであってもよく、プレイヤにより操作されるアバターオブジェクトと、複数のユーザ各々により操作される兵士オブジェクトと、ゲームプログラムにより動作する敵オブジェクトとが登場し、ユーザがアバターオブジェクト６１０を守りながら敵オブジェクトを倒すような参加型ゲームであってもよい。また、仮想空間６００Ｂまたは拡張現実空間内において進行するコンテンツは、ライブゲームに限らず、例えば、アバターオブジェクト６１０がライブで歌っている様子や、ライブでおしゃべりをしている様子をユーザが視聴するための視聴型のコンテンツであってもよい。

（１４）上記実施形態においては、ユーザ端末１００のカメラ１７が、表示部１５２が設けられている面と反対側の面に設けられており、カメラ１７で撮影しているときに表示部１５２に表示される取得画像が、ユーザが直接視認している現実の風景内に含まれている（合致している）ことを想定している。しかし、ユーザ端末１００のカメラ１７は、表示部１５２が設けられている面と反対側の面に設けられているものに限らず、表示部１５２が設けられている面に設けられているもの（ユーザ自身が含まれる取得画像上にアバターオブジェクト６１０等を配置させて動作させるようなもの）であってもよく、ユーザ端末１００と通信可能となるように当該ユーザ端末１００とは別個に設けられているものであってもよい。

（１５）上記実施形態においては、アバターオブジェクト６１０が動作している映像は、リアルタイムレンダリングにより配信される動作指図データに基づいて表示部１５２に表示される。しかし、当該映像は、動画配信方式により配信される例えば３６０°動画データ等に基づいて表示するようにしてもよい。また、３６０°動画データの場合には、視聴モードに応じて制御される視点からの画像を表示するようにしてもよい。

＜付記＞
以上の各実施形態で説明した事項を、以下に付記する。

（付記１）：
本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、入力部、および表示部を備える情報端末装置（ユーザ端末１００）において実行されるプログラムであって、前記プロセッサに、キャラクタが配置されている仮想空間を表示するための表示用データ（動作指図データ）を受信するステップ（Ｓ２６）と、前記仮想空間内において視点を移動させるための態様が異なる複数種類の視聴モードのうちのいずれかを特定するステップ（Ｓ８１、Ｓ８４、Ｓ１０３、Ｓ１０６）と、前記表示用データに基づく仮想空間内の画像のうち、前記特定するステップにより特定されている視聴モードに応じた態様で移動する視点からの画像を前記表示部に表示するステップ（Ｓ８５～Ｓ８７、Ｓ９２、Ｓ９３、Ｓ１０４、Ｓ１０５、Ｓ１１０、Ｓ１１１、Ｓ１１４）とを実行させ、前記複数種類の視聴モードは、ユーザからの前記入力部に対する入力態様に応じて視点を移動可能となる視聴モードとして、前記キャラクタが配置され得る所定の範囲内への視点の移動を規制し得る第１視聴モード（通常モード）と、前記キャラクタが配置され得る所定の範囲内への視点の移動を許容するが当該所定の範囲内に視点を移動させたときには前記キャラクタを非表示とし得る第２視聴モード（ＡＲモード）とを含む。

（付記２）：
（付記１）において、前記入力部は、前記表示部に対する入力操作を特定する第１入力部（タッチスクリーン１５）と、前記情報端末装置の位置を特定する第２入力部（ジャイロセンサ、ＧＰＳなど）とを含み、前記第１視聴モードは、前記第１入力部により特定される操作態様に応じて視点を移動可能となる視聴モードであり、前記第２視聴モードは、前記第２入力部により特定される位置に応じて視点を移動可能となる視聴モードである。

（付記３）：
（付記２）において、前記情報端末装置は撮像部（カメラ１７）を備え、前記第２視聴モードは、前記撮像部により取得された取得画像に対して前記表示用データに基づく前記キャラクタが配置されている拡張現実空間内の画像のうち、前記第２入力部により特定される位置に応じた視点からの画像を表示する視聴モード（ＡＲモード）である。

（付記４）：
（付記１）から（付記３）のいずれかにおいて、前記表示用データは、ユーザの動作態様にかかわらない所定の視点（カメラオブジェクト６３０の視点と同じ視点）を特定するための視点情報を含み、前記複数種類の視聴モードは、前記表示用データに基づく仮想空間内の画像のうち前記視点情報に基づいて特定される所定の視点からの画像を表示する視聴モード（ＴＶモード）を含む。

（付記５）：
（付記１）から（付記４）のいずれかにおいて、前記キャラクタは、演者の動きに応じてリアルタイムに動作するキャラクタであり、前記所定の範囲は、所定位置から演者が移動可能な範囲として予め定められている範囲である。

（付記６）：
（付記１）から（付記４）のいずれかにおいて、前記キャラクタは、演者の動きに応じてリアルタイムに動作するキャラクタであり、前記所定の範囲は、演者の現在位置を基準とする予め定められた範囲である。

（付記７）：
（付記１）から（付記６）のいずれかにおいて、前記所定の範囲は、前記視点が移動した場合に前記キャラクタの特定部位を表示可能となる位置を含む。

（付記８）：
（付記１）から（付記７）のいずれかにおいて、前記第１視聴モードにおける所定の範囲と、前記第２視聴モードにおける所定の範囲とは、同一の範囲である。

（付記９）：
（付記１）から（付記７）のいずれかにおいて、前記第１視聴モードにおける所定の範囲は、前記第２視聴モードにおける所定の範囲よりも広い範囲に定められている。

（付記１０）：
（付記１）から（付記９）のいずれかにおいて、前記第１視聴モードおよび前記第２視聴モードは、いずれも、前記表示部に表示される画像を視聴する同一のユーザからの前記入力部に対する入力態様に応じて移動される視点からの画像を表示する視聴モードである。

（付記１１）：
（付記１）から（付記１０）のいずれかにおいて、前記キャラクタには、予め定められた特定のオブジェクトが関連付けられており、前記特定のオブジェクトの表示態様は、前記情報端末装置を所有するユーザからの要求の有無にかかわらず変更され、前記第２視聴モードである場合には、前記キャラクタに関連付けられている前記特定のオブジェクトを表示可能となる位置に視点を移動可能であり、前記第１視聴モードである場合には、前記キャラクタに関連付けられている前記特定のオブジェクトを表示可能となる位置に視点を移動不可能である。

（付記１２）：
本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、入力部、および表示部を備える情報端末装置（ユーザ端末１００）において実行される方法であって、前記情報端末装置が、キャラクタが配置されている仮想空間を表示するための表示用データ（動作指図データ）を受信するステップ（Ｓ２６）と、前記仮想空間内において視点を移動させるための態様が異なる複数種類の視聴モードのうちのいずれかを特定するステップ（Ｓ８１、Ｓ８４、Ｓ１０３、Ｓ１０６）と、前記表示用データに基づく仮想空間内の画像のうち、前記特定するステップにより特定されている視聴モードに応じた態様で移動する視点からの画像を前記表示部に表示するステップ（Ｓ８５～Ｓ８７、Ｓ９２、Ｓ９３、Ｓ１０４、Ｓ１０５、Ｓ１１０、Ｓ１１１、Ｓ１１４）とを備え、前記複数種類の視聴モードは、ユーザからの前記入力部に対する入力態様に応じて視点を移動可能となる視聴モードとして、前記キャラクタが配置され得る所定の範囲内への視点の移動を規制し得る第１視聴モード（通常モード）と、前記キャラクタが配置され得る所定の範囲内への視点の移動を許容するが当該所定の範囲内に視点を移動させたときには前記キャラクタを非表示とし得る第２視聴モード（ＡＲモード）とを含む。

（付記１３）：
本開示に示す一実施形態のある局面によれば、情報端末装置（ユーザ端末１００）であって、プログラムを記憶する記憶部と、前記プログラムを実行することにより、前記情報処理装置の動作を制御する制御部を備え、前記制御部は、キャラクタが配置されている仮想空間を表示するための表示用データ（動作指図データ）を受信するステップ（Ｓ２６）と、前記仮想空間内において視点を移動させるための態様が異なる複数種類の視聴モードのうちのいずれかを特定するステップ（Ｓ８１、Ｓ８４、Ｓ１０３、Ｓ１０６）と、前記表示用データに基づく仮想空間内の画像のうち、前記特定するステップにより特定されている視聴モードに応じた態様で移動する視点からの画像を前記表示部に表示するステップ（Ｓ８５～Ｓ８７、Ｓ９２、Ｓ９３、Ｓ１０４、Ｓ１０５、Ｓ１１０、Ｓ１１１、Ｓ１１４）とを実行し、前記複数種類の視聴モードは、ユーザからの前記入力部に対する入力態様に応じて視点を移動可能となる視聴モードとして、前記キャラクタが配置され得る所定の範囲内への視点の移動を規制し得る第１視聴モード（通常モード）と、前記キャラクタが配置され得る所定の範囲内への視点の移動を許容するが当該所定の範囲内に視点を移動させたときには前記キャラクタを非表示とし得る第２視聴モード（ＡＲモード）とを含む。

〔ソフトウェアによる実現例〕
ユーザ端末１００、サーバ２００、ゲームプレイ端末３００（ＨＭＤセット１０００）、および配信端末４００の制御ブロック（特に制御部１１０、２１０、３１０、４１０）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ソフトウェアによって実現してもよい。

後者の場合、ユーザ端末１００、サーバ２００、ゲームプレイ端末３００（ＨＭＤセット１０００）、および配信端末４００は、各機能を実現するソフトウェアであるプログラムの命令を実行するコンピュータを備えている。このコンピュータは、例えば１つ以上のプロセッサを備えていると共に、上記プログラムを記憶したコンピュータ読み取り可能な記録媒体を備えている。そして、上記コンピュータにおいて、上記プロセッサが上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記プロセッサとしては、例えばＣＰＵ（Central Processing Unit）を用いることができる。上記記録媒体としては、「一時的でない有形の媒体」、例えば、ＲＯＭ（Read Only Memory）等の他、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムを展開するＲＡＭ（Random Access Memory）などをさらに備えていてもよい。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

１システム、２ネットワーク、３、３Ａ、３Ｂユーザ（第１ユーザ）、４プレイヤ（演者）、１０，２０，３０，４０プロセッサ、１１，２１，３１，４１メモリ、１２，２２，３２，４２ストレージ、１３，２３，３３，４３通信ＩＦ、１４，２４，３４，４４入出力ＩＦ、１５，４５タッチスクリーン、１７カメラ、１８測距センサ、５１モニタ、５２注視センサ、５３第１カメラ、５４第２カメラ、５５マイク、５６スピーカ、１００，１００Ａ，１００Ｂ，１００Ｃユーザ端末（コンピュータ、第１コンピュータ、第１情報処理装置）、１１０，２１０，３１０，４１０制御部（第１制御部、第２制御部）、１１１，３１１，４１３操作受付部、１１２，３１２，４１２表示制御部、１１３，３１３ＵＩ制御部、１１４，３１４アニメーション生成部、１１５，３１５ゲーム進行部、１１６，３１６仮想空間制御部、１１７動画再生部、１２０，２２０，３２０，４２０記憶部（第１記憶部、第２記憶部）、１３１，２３１，３３１ゲームプログラム（プログラム、第１プログラム）、１３２，２３２，３３２ゲーム情報、１３３，２３３，３３３ユーザ情報、１５１，４５１入力部、１５２，４５２表示部（ディスプレイ）、２００サーバ、２１１通信仲介部、２１２ログ生成部、２１３リスト生成部、２３４，４２１ユーザリスト、３００ゲームプレイ端末（外部装置、第２外部装置）、３１７反応処理部、４００配信端末（外部、第１外部装置、コンピュータ、第２情報処理装置）、４１１通信制御部、４１４音声受付部、４１５モーション特定部、４１６動作指図データ生成部、４２２モーションリスト、４２３配信プログラム（プログラム、第２プログラム）、５４０，１０２０，１０２１コントローラ、５００ＨＭＤ、５１０ＨＭＤセンサ、５２０モーションセンサ、５３０ディスプレイ、６００Ａ、６００Ｂ仮想空間、６１０アバターオブジェクト（キャラクタ）、６２０Ａ，６２０Ｂ仮想カメラ、６３１，６３２，６３３，６３４オブジェクト、６４０Ａ，６４０Ｂ視界領域、６５０，６６０視界画像、６７１敵オブジェクト、６７２，６７３障害物オブジェクト、６７４演出オブジェクト、６９１，６９２発話、７０１，７０２，７０３Ａ，７０Ｂ，７０４Ａ，７０４Ｂ，７０５，７０６，７１１，７１１Ａ，７１１Ｂ，７１１Ｃ，７１１Ｄ，７２２，７２３，７４５，７４５Ａ，７４５Ｂ，７４５Ｃ，７５２，７６２，７６３，９３０，２０１１、２０２２、２０３１、２０３２、２０３３、２０３４、２０３７、２０３８、２０５１、２０６３、２０７２、２０７３、２０７５ＵＩ画像（メッセージＵＩ、ＵＩ）、７２１ダウンロード画面、７３１ユーザリスト画面（リスト）、７３２，７３２Ａ，７３２Ｂ，７３２Ｃ，７４２，７４２Ａ，７４２Ｂ，７４２Ｃレコード画像、７３３，７３３Ａ，７３３Ｂ，７３３Ｃユーザ名、７３４，７３４Ａ，７３４Ｂ，７３４Ｃタグ情報、７３５，７３５Ａ，７３５Ｂ，７３５Ｃアイコン、７４１モーションリスト画面（選択肢）、７４３，７４３Ａ，７４３Ｂ，７４３Ｃモーション名、７４４，７４４Ａ，７４４Ｂ，７４４Ｃ，７５３モーション画像、７５１配信画面、７６１配信完了画面、８１０Ａ，８１０Ｂモーション動画、８２０Ａ，８２０Ｂ発話音声、９１０Ａ，９１０Ｂ動画、９２０Ａ，９２０Ｂ音声、１０００ＨＭＤセット、１０１０物体、１０３０記憶媒体、２０１０ホーム画面、２０２０ランキング画面、２０２１タイトル画像、２０２６，２０２６Ａ，２０２６Ｂ順位、２０２７，２０２７Ａ，２０２７Ｂ課金額、２０２８，２０２８Ａ，２０２８Ｂ送信回数、２０２９送信済通知、２０３０前回送信日、２０３５詳細表示領域、２０３６スクロールバー、２０４０詳細画面、２０５０，２０６０準備画面、２０５２テキスト、２０５３、２０６１選択画像、２０５４Ａ、２０５４Ｂ、２０５４Ｃ、２０６２Ａ，２０６２Ｂ，２０６２Ｃ，２０６２Ｄ，２０６２Ｅ，２０６２Ｆ選択肢、２０７０音声入力画面、２０７４タグ画像

Claims

プロセッサ、メモリ、入力部、および表示部を備える情報端末装置において実行されるプログラムであって、
前記プロセッサに、
キャラクタが配置されている仮想空間を表示するための表示用データを受信するステップと、
前記仮想空間内において視点を移動させるための態様が異なる複数種類の視聴モードのうちのいずれかを特定するステップと、
前記表示用データに基づく仮想空間内の画像のうち、前記特定するステップにより特定されている視聴モードに応じた態様で移動する視点からの画像を前記表示部に表示するステップとを実行させ、
前記複数種類の視聴モードは、ユーザからの前記入力部に対する入力態様に応じて視点を移動可能となる視聴モードとして、前記キャラクタが配置され得る所定の範囲内への視点の移動を規制し得る第１視聴モードと、前記キャラクタが配置され得る所定の範囲内への視点の移動を許容するが当該所定の範囲内に視点を移動させたときには前記キャラクタを非表示とし得る第２視聴モードとを含む、プログラム。
前記入力部は、前記表示部に対する入力操作を特定する第１入力部と、前記情報端末装置の位置を特定する第２入力部とを含み、
前記第１視聴モードは、前記第１入力部により特定される操作態様に応じて視点を移動可能となる視聴モードであり、
前記第２視聴モードは、前記第２入力部により特定される位置に応じて視点を移動可能となる視聴モードである、請求項１に記載のプログラム。
前記情報端末装置は撮像部を備え、
前記第２視聴モードは、前記撮像部により取得された取得画像に対して前記表示用データに基づく前記キャラクタが配置されている拡張現実空間内の画像のうち、前記第２入力部により特定される位置に応じた視点からの画像を表示する視聴モードである、請求項２に記載のプログラム。
前記表示用データは、ユーザの動作態様にかかわらない所定の視点を特定するための視点情報を含み、
前記複数種類の視聴モードは、前記表示用データに基づく仮想空間内の画像のうち前記視点情報に基づいて特定される所定の視点からの画像を表示する視聴モードを含む、請求項１～請求項３のいずれかに記載のプログラム。
前記キャラクタは、演者の動きに応じてリアルタイムに動作するキャラクタであり、
前記所定の範囲は、所定位置から演者が移動可能な範囲として予め定められている範囲である、請求項１～請求項４のいずれかに記載のプログラム。
前記キャラクタは、演者の動きに応じてリアルタイムに動作するキャラクタであり、
前記所定の範囲は、演者の現在位置を基準とする予め定められた範囲である、請求項１～請求項４のいずれかに記載のプログラム。
前記所定の範囲は、前記視点が移動した場合に前記キャラクタの特定部位を表示可能となる位置を含む、請求項１～請求項６のいずれかに記載のプログラム。
前記第１視聴モードにおける所定の範囲と、前記第２視聴モードにおける所定の範囲とは、同一の範囲である、請求項１～請求項７のいずれかに記載のプログラム。
前記第１視聴モードにおける所定の範囲は、前記第２視聴モードにおける所定の範囲よりも広い範囲に定められている、請求項１～請求項７のいずれかに記載のプログラム。
前記第１視聴モードおよび前記第２視聴モードは、いずれも、前記表示部に表示される画像を視聴する同一のユーザからの前記入力部に対する入力態様に応じて移動される視点からの画像を表示する視聴モードである、請求項１～請求項９のいずれかに記載のプログラム。
前記キャラクタには、予め定められた特定のオブジェクトが関連付けられており、
前記特定のオブジェクトの表示態様は、前記情報端末装置を所有するユーザからの要求の有無にかかわらず変更され、
前記第２視聴モードである場合には、前記キャラクタに関連付けられている前記特定のオブジェクトを表示可能となる位置に視点を移動可能であり、
前記第１視聴モードである場合には、前記キャラクタに関連付けられている前記特定のオブジェクトを表示可能となる位置に視点を移動不可能である、請求項１～請求項１０のいずれかに記載のプログラム。
プロセッサ、メモリ、入力部、および表示部を備える情報端末装置において実行される方法であって、
前記情報端末装置が、
キャラクタが配置されている仮想空間を表示するための表示用データを受信するステップと、
前記仮想空間内において視点を移動させるための態様が異なる複数種類の視聴モードのうちのいずれかを特定するステップと、
前記表示用データに基づく仮想空間内の画像のうち、前記特定するステップにより特定されている視聴モードに応じた態様で移動する視点からの画像を前記表示部に表示するステップとを備え、
前記複数種類の視聴モードは、ユーザからの前記入力部に対する入力態様に応じて視点を移動可能となる視聴モードとして、前記キャラクタが配置され得る所定の範囲内への視点の移動を規制し得る第１視聴モードと、前記キャラクタが配置され得る所定の範囲内への視点の移動を許容するが当該所定の範囲内に視点を移動させたときには前記キャラクタを非表示とし得る第２視聴モードとを含む、方法。
情報端末装置であって、
プログラムを記憶する記憶部と、前記プログラムを実行することにより、前記情報処理装置の動作を制御する制御部を備え、
前記制御部は、
キャラクタが配置されている仮想空間を表示するための表示用データを受信するステップと、
前記仮想空間内において視点を移動させるための態様が異なる複数種類の視聴モードのうちのいずれかを特定するステップと、
前記表示用データに基づく仮想空間内の画像のうち、前記特定するステップにより特定されている視聴モードに応じた態様で移動する視点からの画像を前記表示部に表示するステップとを実行し、
前記複数種類の視聴モードは、ユーザからの前記入力部に対する入力態様に応じて視点を移動可能となる視聴モードとして、前記キャラクタが配置され得る所定の範囲内への視点の移動を規制し得る第１視聴モードと、前記キャラクタが配置され得る所定の範囲内への視点の移動を許容するが当該所定の範囲内に視点を移動させたときには前記キャラクタを非表示とし得る第２視聴モードとを含む、情報端末装置。