JP2021056818A

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

Info

Publication number: JP2021056818A
Application number: JP2019179921A
Authority: JP
Inventors: 潤哉福重; Junya Fukushige
Original assignee: Colopl Inc
Current assignee: Colopl Inc
Priority date: 2019-09-30
Filing date: 2019-09-30
Publication date: 2021-04-08
Anticipated expiration: 2039-09-30
Also published as: JP6826645B1

Abstract

【課題】コストを極力増大させずかつユーザへの違和感を低減できる、プログラム、方法、および端末装置を提供する。【解決手段】仮想空間内に配置されている演者の動きに応じて動作するキャラクタが配置されている仮想空間を表示するとともに演者の発話に応じて音声を出力するためのデータを受信し、データに基づく仮想空間内の画像を所定の表示部に表示可能とし、データに基づく音声を出力可能とし、キャラクタの口元が音声に応じた口元に変更され、キャラクタの表情が時間の経過に伴ってキャラクタの属性に応じた所定のルールに従った表情に変更される。【選択図】図３１

Description

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

従来より、演者によって制御されるバーチャルキャラクタを表示するためのシステムがある。また、このようなシステムにおいては、演者の発話に合わせてバーチャルキャラクタの口の動きを連動させつつ（リップシンク）、バーチャルキャラクタの表情についてはスイッチで切り替えるものがあった。

ＡＶＷａｔｃｈ，VTuber配信を簡単にするniconico「バーチャルキャスト」と「VRM」。スタジオもVR，２０１８年４月１６日，[online]，令和１年６月７日検索，ＵＲＬ，https://av.watch.impress.co.jp/docs/news/1117367.html

しかし、従来のシステムにおいては、表情を切り替えるためにスイッチを操作する人員を配置する必要があるため、人的コストが増大してしまう。また、手動により表情を切り替えるため、表情の切り替えタイミングが実際の演者の動きや発話よりも遅延してしまい、ユーザに違和感を抱かせてしまう。このため、コスト増大に見合うだけの精度を期待することはできなかった。

本発明は、かかる実情に鑑み考え出されたものであり、その目的は、コストを極力増大させずかつユーザへの違和感を低減できる、プログラム、方法、および端末装置を提供することである。

本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、および入力部を備える端末装置において実行されるプログラムであって、プロセッサに、演者の動きに応じて動作するキャラクタが配置されている仮想空間を表示するとともに演者の発話に応じて音声を出力するためのデータを受信するステップと、データに基づく仮想空間内の画像を所定の表示部に表示可能とするステップと、データに基づく音声を出力可能とするステップとを実行させ、表示可能とするステップにより表示される前記キャラクタの口元は、音声に応じた口元に変更され、表示可能とするステップにより表示される前記キャラクタの表情は、時間の経過に伴って、キャラクタの属性に応じた所定のルールに従った表情に変更される。

本発明によれば、コストを極力増大させずかつユーザへの違和感を低減できる。

ある実施の形態に従うシステムの概要の一例を示す図である。ある実施の形態に従うユーザ端末のハードウェア構成の一例を示すブロック図である。ある実施の形態に従うサーバのハードウェア構成の一例を示すブロック図である。ある実施の形態に従うゲームプレイ端末のハードウェア構成の一例を示すブロック図である。ある実施の形態に従う配信端末のハードウェア構成の一例を示すブロック図である。ある実施の形態に従うユーザ端末、サーバ、ＨＭＤセットの機能的構成の一例を示すブロック図である。ある実施の形態に従う配信端末の機能的構成の一例を示すブロック図である。ある実施の形態に従うユーザ端末およびゲームプレイ端末において実行される処理の一部を表すフローチャートである。ある実施の形態に従う、プレイヤに提供される仮想空間、および、プレイヤが視認する視界画像の一例を示す図である。ある実施の形態に従う、ユーザ端末のユーザに提供される仮想空間、および、該ユーザが視認する視界画像の一例を示す図である。ユーザ端末のユーザが視認する視界画像の他の例を示す図である。ユーザ端末のユーザが視認する視界画像のさらに別の例を示す図である。ある実施の形態に従うゲームプレイ端末において実行される処理の一部を表すフローチャートである。ある実施の形態に従うユーザ端末において実行される処理の一部を表すフローチャートである。ある実施の形態に従うサーバにおいて実行される処理の一部を表すフローチャートである。ある実施の形態に従う、ゲームに参加したユーザのリストの一具体例を示す図である。ある実施の形態に従う配信端末において実行される処理の一部を表すフローチャートである。ある実施の形態に従う配信端末に表示される画面の一具体例を示す図である。ある実施の形態に従う配信端末に表示される画面の他の具体例を示す図である。ある実施の形態に従う、プレイヤによる音声入力の一具体例を示す図である。ある実施の形態に従う配信端末に表示される画面のさらなる別の具体例と、動作指図データの配信の概要とを示す図である。ある実施の形態に従う、プレイヤによる音声入力の他の具体例を示す図である。ある実施の形態に従う配信端末に表示される画面のさらなる別の具体例と、動作指図データの配信の概要とを示す図である。ある実施形態に従うゲームプレイ端末からユーザ端末へのゲーム進行情報の送信の概要を示す図である。ある実施の形態に従うユーザ端末において実行される処理の一部を表すフローチャートである。動画再生の一具体例を示す図である。動画再生の他の具体例を示す図である。顔制御処理を説明するための図である。プレイヤの動きに応じて動作するアバターオブジェクトの口元が発話する際の一般的な口形に切替えられるとともに、アバターオブジェクトの表情がランダムに切り替えられたときの表示例を説明するための図である。次に切り替える表情を決定する際に参照する表情特定用テーブルを説明するための図である。顔制御処理を説明するための図である。顔制御処理を説明するための図である。

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

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

プロセッサ、メモリ、および入力部を備える端末装置において実行されるプログラムであって、
前記プロセッサに、
演者の動きに応じて動作するキャラクタが配置されている仮想空間を表示するとともに演者の発話に応じて音声を出力するためのデータを受信するステップと、
前記データに基づく仮想空間内の画像を所定の表示部に表示可能とするステップと、
前記データに基づく音声を出力可能とするステップとを実行させ、
前記表示可能とするステップにより表示される前記キャラクタの口元は、音声に応じた口元に変更され、
前記表示可能とするステップにより表示される前記キャラクタの表情は、時間の経過に伴って、キャラクタの属性に応じた所定のルールに従った表情に変更される、プログラム。
前記所定のルールとは、予め定められている複数種類の表情毎に定められている選択割合で当該複数種類の表情のうちからいずれかを選択することであり、
前記複数種類の表情は、キャラクタの属性に対応する第１の表情と、キャラクタの属性に対応していない第２の表情とを含み、
前記複数種類の表情のうち前記第１の表情の選択割合は、前記第２の表情の選択割合よりも高い、請求項１に記載のプログラム。
前記キャラクタの表情は、複数種類の表情のうちのいずれかに変更され、
前記複数種類の表情は、キャラクタの属性に対応する第１の表情と、キャラクタの属性に対応していない第２の表情とを含み、
変更された表情が前記キャラクタの表情として前記表示可能とするステップにより表示される時間は、前記第２の表情であるときよりも前記第１の表情であるときの方が長い、請求項１または請求項２に記載のプログラム。
前記キャラクタの表情は、複数種類の表情のうちのいずれかに変更され、
前記複数種類の表情は、キャラクタの属性に対応する第１の表情と、キャラクタの属性に対応していない第２の表情とを含み、
前記表示可能とするステップにより表示される前記キャラクタの表情は、演者の発話音量が閾値を超えることにより前記第１の表情に変更される、請求項１〜請求項３のいずれかに記載のプログラム。
演者の発話音量が閾値を超えることにより前記第１の表情に変更されてから前記演者の発話音量が第１の値を超えている期間においては、前記表示可能とするステップにより表示される前記キャラクタの表情が前記第１の表情となる、請求項４に記載のプログラム。
演者の発話音量が閾値を超えることにより前記第１の表情に変更されてから第１時間が経過するまで、前記表示可能とするステップにより表示される前記キャラクタの表情が前記第１の表情となる、請求項４に記載のプログラム。
前記データは、外部から配信されるデータであって、前記演者の入力したモーションに対応するモーションデータおよび前記演者の発話に対応する発話データを含み、
前記表示可能とするステップは、前記データのうちのモーションデータに基づいて前記仮想空間内において前記キャラクタをリアルタイムに動作させ、
前記出力可能とするステップは、前記データのうちの発話データに基づいて、前記演者の発話に応じた音声を出力する、請求項１〜請求項６のいずれかに記載のプログラム。
前記データは、前記所定のルールで変更された表情を特定するための第１のデータを含み、
前記表示可能とするステップは、前記データのうちの前記第１のデータに基づいて前記キャラクタの表情を設定する、請求項７に記載のプログラム。
前記データは、外部から配信されるデータであって、前記所定のルールで表情が変更されたキャラクタが前記仮想空間内において動作する映像を含む動画データであり、
前記表示可能とするステップは、前記動画データに基づいて前記仮想空間内で前記キャラクタが動作する映像を表示する、請求項１〜６のいずれかに記載のプログラム。
プロセッサ、メモリ、および入力部を備える端末装置が実行する方法であって、
演者の動きに応じて動作するキャラクタが配置されている仮想空間を表示するとともに演者の発話に応じて音声を出力するためのデータを受信するステップと、
前記データに基づく仮想空間内の画像を所定の表示部に表示可能とするステップと、
前記データに基づく音声を出力可能とするステップとを備え、
前記表示可能とするステップにより表示される前記キャラクタの口元は、音声に応じた口元に変更され、
前記表示可能とするステップにより表示される前記キャラクタの表情は、時間の経過に伴って、キャラクタの属性に応じた所定のルールに従った表情に変更される、方法。
プロセッサ、メモリ、および入力部を備える端末装置であって、
演者の動きに応じて動作するキャラクタが配置されている仮想空間を表示するとともに演者の発話に応じて音声を出力するためのデータを受信するステップと、
前記データに基づく仮想空間内の画像を所定の表示部に表示可能とするステップと、
前記データに基づく音声を出力可能とするステップとを備え、
前記表示可能とするステップにより表示される前記キャラクタの口元は、音声に応じた口元に変更され、
前記表示可能とするステップにより表示される前記キャラクタの表情は、時間の経過に伴って、キャラクタの属性に応じた所定のルールに従った表情に変更される、端末装置。