JP6578079B1 - 端末、サーバおよびプログラム - Google Patents

Abstract

【課題】新規なリアルタイムコンテンツ体験を提供する。【解決手段】本発明の一態様によれば、端末は、リアルタイムコンテンツを再生可能であって、取得部と、送信部と、状態制御部と、描画部とを含む。取得部は、（１）リアルタイムコンテンツに含まれる仮想オブジェクト、および（２）リアルタイムコンテンツとともに再生されるコンテンツ、のうちの少なくとも１つの状態を制御するための第１のユーザ入力を取得する。送信部は、第１のユーザ入力をサーバへ送信する。状態制御部は、第１のユーザ入力のなされた画面内位置に基づいて状態を決定する。描画部は、決定された状態に応じて、仮想オブジェクトおよびコンテンツの少なくとも１つを、サーバから受信され、または端末によって作成されたリアルタイムコンテンツの映像データに単位時間毎に重畳して再描画する。【選択図】 図２

Description

本発明は、リアルタイムのコンテンツ体験に関する。

従来、動画などのコンテンツの生放送（配信）サービスでは、観客がコメントを投稿し、配信者が投稿されたコメントに反応するという双方向的な視聴体験が可能である。近年では、いわゆるギフト機能を実装した生放送サービスも提案されているが、これも双方向的な視聴体験に寄与すると考えられる。

さらに、一部の生放送サービスでは、従来のライブ動画と共に楽しむことのできるゲームが実験的に提供されている。例えば非特許文献１には、釣りをするシロクマをクリックおよびタップで操作しアイテムを釣り上げ、それに応じて得られるポイントを配信者と観客との間で競うことのできるゲームが紹介されている。

「つりっくまとは」、［ｏｎｌｉｎｅ］、［２０１９年２月１１日検索］、インターネット、＜ＵＲＬ：ｈｔｔｐ：／／ｄｉｃ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ａ／つりっくま＞

本発明は、新規なリアルタイムコンテンツ体験を提供することを目的とする。

本発明の第１の態様によれば、端末は、リアルタイムコンテンツを再生可能であって、取得部と、送信部と、受信部と、遷移制御部と、検出部と、描画部とを含む。取得部は、リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームを第１のゲーム状態から第２のゲーム状態に遷移させるための第１のユーザ入力を取得する。送信部は、第１のユーザ入力をサーバへ送信する。受信部は、リアルタイムコンテンツを再生する１以上の他の端末によって取得された、リアルタイムゲームにおいてキャラクタの移動を制御するための第２のユーザ入力をサーバから受信する。遷移制御部は、第１のユーザ入力の履歴に基づいて、リアルタイムゲームの第１のゲーム状態から第２のゲーム状態への遷移を制御する。検出部は、キャラクタのうちリアルタイムゲームが第２のゲーム状態にある時に移動中であるキャラクタを第２のユーザ入力に基づいて検出する。描画部は、リアルタイムゲームが第１のゲーム状態にある間に、キャラクタのうちリアルタイムゲームが第２のゲーム状態にある時に移動中であるとして検出されなかったキャラクタを、第２のユーザ入力の履歴に依存して決まる位置に、サーバから受信され、または端末によって作成されたリアルタイムコンテンツの映像データに単位時間毎に重畳して再描画する。

本発明の第２の態様によれば、端末は、リアルタイムコンテンツを再生可能であって、取得部と、送信部と、受信部と、遷移制御部と、検出部と、描画部とを含む。取得部は、リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームにおいて第１のキャラクタの移動を制御するための第１のユーザ入力を取得する。送信部は、第１のユーザ入力をサーバへ送信する。受信部は、リアルタイムコンテンツを再生する１以上の第１の端末によって取得された、リアルタイムゲームにおいて第１のキャラクタとは異なる１以上の第２のキャラクタの移動を制御するための第２のユーザ入力と、リアルタイムコンテンツを再生する第２の端末によって取得された、リアルタイムゲームを第１のゲーム状態から第２のゲーム状態へ遷移させるための第３のユーザ入力とをサーバから受信する。遷移制御部は、第３のユーザ入力の履歴に基づいて、リアルタイムゲームの第１のゲーム状態から第２のゲーム状態への遷移を制御する。検出部は、第１のキャラクタおよび第２のキャラクタのうちリアルタイムゲームが第２のゲーム状態にある時に移動中であるキャラクタを第１のユーザ入力および第２のユーザ入力に基づいて検出する。描画部は、リアルタイムゲームが第１のゲーム状態にある間に、第１のキャラクタおよび第２のキャラクタのうちリアルタイムゲームが第２のゲーム状態にある時に移動中であるとして検出されていないキャラクタを、第１のユーザ入力の履歴および第２のユーザ入力の履歴に依存して決まる位置に、サーバから受信され、または端末によって作成されたリアルタイムコンテンツの映像データに単位時間毎に重畳して再描画する。

本発明の第３の態様によれば、端末は、リアルタイムコンテンツを再生可能であって、受信部と、遷移制御部と、検出部と、描画部とを含む。受信部は、リアルタイムコンテンツを再生する第１の端末によって取得された、リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームを第１のゲーム状態から第２のゲーム状態へ遷移させるための第１のユーザ入力と、リアルタイムコンテンツを再生する１以上の第２の端末によって取得された、リアルタイムゲームにおいてキャラクタの移動を制御するための第２のユーザ入力とをサーバから受信する。遷移制御部は、第１のユーザ入力の履歴に基づいて、リアルタイムゲームの第１のゲーム状態から第２のゲーム状態への遷移を制御する。検出部は、キャラクタのうちリアルタイムゲームが第２のゲーム状態にある時に移動中であるキャラクタを第２のユーザ入力に基づいて検出する。描画部は、リアルタイムゲームが第１のゲーム状態にある間に、キャラクタのうちリアルタイムゲームが第２のゲーム状態にある時に移動中であるとして検出されていないキャラクタを、第２のユーザ入力の履歴に依存して決まる位置に、サーバから受信され、または端末によって作成されたリアルタイムコンテンツの映像データに単位時間毎に重畳して再描画する。

本発明の第４の態様によれば、サーバは、リアルタイムコンテンツを配信可能であって、受信部と、遷移制御部と、検出部と、描画部と、送信部とを含む。受信部は、リアルタイムコンテンツの映像データをリアルタイムコンテンツのソースとなる第１の端末から受信し、リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームを第１のゲーム状態から第２のゲーム状態へ遷移させるための第１のユーザ入力をリアルタイムコンテンツを再生する第２の端末から受信し、キャラクタの移動を制御するための第２のユーザ入力をリアルタイムコンテンツを再生する１以上の第３の端末から受信する。遷移制御部は、第１のユーザ入力の履歴に基づいて、リアルタイムゲームの第１のゲーム状態から第２のゲーム状態への遷移を制御する。検出部は、キャラクタのうちリアルタイムゲームが第２のゲーム状態にある時に移動中であるキャラクタを第２のユーザ入力に基づいて検出する。描画部は、リアルタイムゲームが第１のゲーム状態にある間に、キャラクタのうちリアルタイムゲームが第２のゲーム状態にある時に移動中であるとして検出されていないキャラクタを、第２のユーザ入力の履歴に依存して決まる位置に、単位時間毎にリアルタイムコンテンツの映像データに重畳して再描画する。送信部は、再描画されたキャラクタを重畳したリアルタイムコンテンツの映像データを第１の端末、第２の端末および第３の端末へ送信する。

本発明の第５の態様によれば、サーバは、リアルタイムコンテンツを配信可能であって、受信部と、遷移制御部と、管理部と、検出部と、送信部とを含む。受信部は、リアルタイムコンテンツの映像データをリアルタイムコンテンツのソースとなる第１の端末から受信し、リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームを第１のゲーム状態から第２のゲーム状態へ遷移させるための第１のユーザ入力をリアルタイムコンテンツを再生する第２の端末から受信し、キャラクタの移動を制御するための第２のユーザ入力をリアルタイムコンテンツを再生する１以上の第３の端末から受信する。遷移制御部は、第１のユーザ入力の履歴に基づいて、リアルタイムゲームの第１のゲーム状態から第２のゲーム状態への遷移を制御する。管理部は、第２のユーザ入力の履歴に基づいて、キャラクタの位置を管理する。検出部は、キャラクタのうちリアルタイムゲームが第２のゲーム状態にある時に移動中であるキャラクタを第２のユーザ入力に基づいて検出する。送信部は、（ａ）リアルタイムコンテンツの映像データと、キャラクタの位置を示すデータと、キャラクタのうちリアルタイムゲームが第２のゲーム状態にある時に移動中であるとして検出されたキャラクタを示すデータとを第１の端末、第２の端末および第３の端末へ送信し、（ｂ）リアルタイムゲームの第１のゲーム状態から第２のゲーム状態へ遷移する時に、リアルタイムゲームが第２のゲーム状態に遷移したことの通知を第１の端末、第２の端末および第３の端末へ送信する。

なお、第４および第５の態様に係るサーバにおいて、第２の端末は、配信者端末であってもよいし、観客端末であってもよい。前者の場合には第１の端末および第２の端末は同一であり、後者の場合には第１の端末および第２の端末は異なる。同様に、第３の端末は、配信者端末であってもよいし、観客端末であってもよい。前者の場合には第１の端末および第３の端末は同一であり、後者の場合には第１の端末および第３の端末は異なる。

本発明の第６の態様によれば、端末は、リアルタイムコンテンツを再生可能であって、取得部と、送信部と、状態制御部と、描画部とを含む。取得部は、（１）リアルタイムコンテンツに含まれる仮想オブジェクト、および（２）リアルタイムコンテンツとともに再生されるコンテンツ、のうちの少なくとも１つの状態を制御するための第１のユーザ入力を取得する。送信部は、第１のユーザ入力をサーバへ送信する。状態制御部は、第１のユーザ入力のなされた画面内位置に基づいて状態を決定する。描画部は、決定された状態に応じて、仮想オブジェクトおよびコンテンツの少なくとも１つを、サーバから受信され、または端末によって作成されたリアルタイムコンテンツの映像データに単位時間毎に重畳して再描画する。

本発明によれば、新規なリアルタイムコンテンツ体験を提供することを目的とすることができる。

第１の実施形態に係る配信者端末および観客端末を含むライブ動画配信システムを例示するブロック図。 第１の実施形態に係る配信者端末を例示するブロック図。 図２の配信者端末によって作成されるライブ動画を例示する図。 図３のライブ動画の配信時にリアルタイムゲームが起動されている場合に、図２の配信者端末の出力装置に表示される画面を例示する図。 図３のライブ動画の配信時にリアルタイムゲームが起動されている場合に、図２の配信者端末の出力装置に表示される画面を例示する図。 第１の実施形態に係る観客端末を例示するブロック図。 図３のライブ動画の配信時にリアルタイムゲームが起動されている場合に、図６の観客端末の出力装置に表示される画面を例示する図。 図２の配信者端末の動作を例示するフローチャート。 図６の観客端末の動作を例示するフローチャート。 第２の実施形態に係る動画配信サーバを例示するブロック図。 図１０の動画配信サーバの動作を例示するフローチャート。

以下、図面を参照しながら実施形態の説明を述べる。なお、以降、説明済みの要素と同一または類似の要素には同一または類似の符号を付し、重複する説明については基本的に省略する。例えば、複数の同一または類似の要素が存在する場合に、各要素を区別せずに説明するために共通の符号を用いることがあるし、各要素を区別して説明するために当該共通の符号に加えて枝番号を用いることもある。

なお、実施形態の説明では、リアルタイムコンテンツとしてライブ動画を仮定するが、リアルタイムコンテンツは動画とは異なる種類のコンテンツ（例えば、静止画、テキスト、など）であってもよい。また、ライブ動画とは、動画ソース（例えば、配信者端末）から動画配信サーバへのアップロードと、その配信とがリアルタイムに行われる動画全般を指しており、その題材は特に限定されない。具体的には、ライブ動画は、配信者による単なる撮影動画（例えば、自撮り動画、定点カメラの映像、ドライブレコーダーの映像、など）、配信者の実演（例えば、配信者による、歌唱、ダンスなどのパフォーマンス、ゲームプレイ、トーク、など）を撮影した動画、配信者が例えばゲームなどの対象について実況／解説を行う実況動画、配信者の分身であるアバターが存在する仮想空間の映像を仮想カメラにより撮影したＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）動画、などであり得る。

（第１の実施形態）
第１の実施形態に係る配信者端末および観客端末は、図１に例示されるライブ動画配信システムに組み込むことができる。このシステムは、実施形態に係る配信者端末１００と、観客端末２００と、動画配信サーバ３００とを含む。動画配信サーバ３００は、各種端末と例えばインターネットなどのネットワーク経由で接続されており、互いにデータを送受信し得る。また、動画配信サーバ３００は、他の図示されないサーバ、例えばＷｅｂサーバ、コメントサーバ、などともネットワーク経由で接続され、互いにデータを送受信し得る。

配信者端末１００、観客端末２００および動画配信サーバ３００は、以下に説明するように、ライブ動画配信サービスを授受するための基本的な機能を有する。

配信者端末１００は、逐次、例えば配信者端末１００に接続されたカメラ／マイクロフォンによって生成された映像／音声データをエンコードし、エンコード済み（マルチメディア）データを動画配信サーバ３００へ送信（アップロード）する。

配信者端末１００は、コンピュータなどの電子デバイス、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、モバイル端末（例えば、タブレット、スマートフォン、ラップトップ、フィーチャーフォン、ポータブルゲーム機、など）、ＶＲ端末、ＡＲ(Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ)端末、ゲーム機、テレビ受像機（インターネットテレビを含む）、などであり得るが、これらに限られない。

動画配信サーバ３００は、配信者端末１００からエンコード済みデータを受信し、これに対して、例えば、再エンコード、ＨＬＳ（ＨＴＴＰ （Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ） Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ）形式への変換、などの加工を必要に応じて行う。動画配信サーバ３００は、（加工後の）エンコード済みデータを配信者端末１００および観客端末２００へ配信する。すなわち、動画配信サーバ３００は、ライブ動画を含むリアルタイムコンテンツを配信可能なサーバである。

観客端末２００は、動画配信サーバ３００からエンコード済みデータを受信し、これをデコードし、ライブ動画（音声を含む）を再生する。すなわち、観客端末２００は、ライブ動画を含むリアルタイムコンテンツを再生可能な端末である。配信者端末１００も、観客端末２００と同様に、動画配信サーバ３００からエンコード済みデータを受信し、これをデコードし、ライブ動画を再生し得る。或いは、配信者端末１００は、動画配信サーバ３００からエンコード済みデータを受信せず、自ら作成したライブ動画の映像データを再生してもよい。すなわち、配信者端末１００は、ライブ動画を含むリアルタイムコンテンツのソースであるとともにこれを再生可能な端末であり得る。

なお、観客端末２００は、逐次、図示されないコメントサーバからライブ動画に対して当該観客端末２００の操作者もしくはその他の観客、または配信者によって投稿されたコメントデータを受信し、当該コメントデータの示すコメントをライブ動画に重畳して表示してもよい。コメントは、ライブ動画の表示領域の右端から左端に向かって移動するように所定時間に亘って表示されてよい。他方、観客端末２００は、ユーザからのテキスト入力に基づいてライブ動画に投稿するコメントデータを生成し、コメントサーバへ送信し得る。これにより、配信者および観客は、ライブ動画の配信中であってもテキストベースでコミュニケーションを取ることが可能となる。

観客端末２００は、配信者端末１００と同様の電子デバイスであり得る。ただし、観客端末２００は、映像／音声データを取り込んだり、これをエンコードしたりする能力は必要とされない。

そして、第１の実施形態に係る配信者端末１００および観客端末２００は、かかるライブ動画配信サービスを授受するための基本的な機能に加えて、当該ライブ動画の配信時に起動可能な（リアルタイム）ゲームをプレイする機能を有する。

このゲームは、配信者のみが起動できるものであってもよいし、課金などの条件付きまたは無条件で観客が起動できるものであってもよいし、図１のライブ動画配信システムの運営者が起動できるものであってもよい。

このゲームの具体的態様は、特に制限されないが、例えば「だるまさんがころんだ」のような、プレイヤー間の心理戦を題材としたゲームであり得る。具体的には、かかるゲームでは、プレイヤー、すなわち配信者および観客は、第１の役割と第２の役割とに分かれる。典型的には、配信者が第１の役割を担うが、配信者以外の観客が第１の役割を担ってもよい。かかるゲームにおいて、第１の役割のプレイヤーは、ゲーム状態の転換点となるタイミング、すなわちゲーム状態が遷移するタイミングをある程度自由に決定し、第２の役割のプレイヤーはかかるタイミングを予測してリスクを冒しながら行動し、勝利または高得点を目指す。なお、第１の役割のプレイヤーは、１人に限らず複数人であってもよい。また、ゲームは、「鬼ごっこ」のようなリアルタイムに状況が変わる遊びを題材としてもよい。

「だるまさんがころんだ」を例に取れば、だるま（鬼）が第１の役割に相当し、参加者が第２の役割に相当する。だるまは、「だるまさんがころんだ」のかけ声を唱えた後に振り向き、その時点で移動を止めていないキャラクタ（参加者役のプレイヤーのアバター）を捕まえることができる。捕まえられたキャラクタはゲームから脱落する。全てのキャラクタが脱落すれば、だるま役のプレイヤーの勝利である。故に、だるま役のプレイヤーは、「だるまさんがころんだ」のかけ声を唱える速さに変化を付けて、参加者役のプレイヤーの予想しないタイミングでだるまを振り向かせようと試みる。他方、参加者役のプレイヤーは、当該プレイヤーが操作するキャラクタが他のキャラクタよりも早くだるまに触れれば勝利となる。故に、参加者役のプレイヤーは、だるまが振り向くタイミングを予想して、だるまが振り向かないうちにキャラクタを最大限に移動させる。

かかるゲームにおいて、第１の役割のプレイヤーのＵＩ（以降、単に第１のＵＩと称する）と、第２の役割のプレイヤーのＵＩ（以降、単に第２のＵＩと称する）とは異なっていてもよい。例えば、第１のＵＩには、ゲーム状態の遷移の進行度を表示するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）部品（ウィジェット）、例えばシークバー、などが含まれてもよい。また、このＧＵＩ部品は、ゲーム状態を遷移させるためのユーザ入力に対応する入力イベントを発生させてもよい。例えば、かかるユーザ入力は、第１の役割のプレイヤーがシークバーのスライダの位置を動かす操作を行った時に発生してもよい。これにより、第１の役割のプレイヤーは、ゲーム状態の遷移の進行の速さなどを直感的に操ることができる。他方、第２のＵＩには、第１のＵＩに比べて粗い精度でゲーム状態の遷移の進行度を視覚的に把握させるためのＧＵＩ部品、画像、テキスト、などが表示されてもよいし、かかるＧＵＩ部品などが全く表示されなくてもよい。

第１の実施形態では、第１の役割のプレイヤーの端末（配信者端末１００または観客端末２００）、および第２の役割のプレイヤーの端末は、それぞれ取得したユーザ入力を互いに動画配信サーバ３００を介して送信し合う。そして、各端末は、自ら取得したユーザ入力と動画配信サーバ３００を介して受信したユーザ入力とに基づいて、ゲーム処理を分散的に行う。すなわち、各端末は、各キャラクタの状態（例えば、現在位置または移動量、脱落者か否かを表すフラグ、など）を管理し、ゲーム状態の遷移を制御し、ゲーム状態に応じたゲーム画面をライブ動画の映像データに重畳して描画する。なお、ユーザ入力は、動画配信サーバ３００に限らず他のサーバ、例えばゲームサーバを介してやり取りされてもよい。

なお、後述するように、第２の実施形態では、動画配信サーバ３００が、各端末からユーザ入力を受信し、ゲーム処理を集中的に行う。すなわち、動画配信サーバ３００は、各キャラクタの状態を管理し、ゲーム状態の遷移を制御し、ゲーム状態に応じたゲーム画面をライブ動画の映像データに重畳して再描画してこれを各端末へ送信する。なお、ここで説明したゲーム処理またはその一部は、動画配信サーバ３００に限らず他のサーバ、例えばゲームサーバによって行われてもよい。

なお、図１において示される各装置の数は、例示に過ぎない。例えば、観客端末２００の数は、時々刻々と変化するので、０となることがあり得るし、数百、数千となることもあり得る。また、図１のライブ動画配信システムは、複数のライブ動画を並列的に生放送することができるので、配信者端末１００の数も複数となり得る。さらに、図１に示されないＷｅｂサーバ、コメントサーバなどがさらに設けられてもよい。

以下、図２乃至図５を用いて、第１の役割のプレイヤーの端末としての配信者端末１００の構成について詳しく説明する。なお、以降の説明では、配信者が第１の役割のプレイヤーであることを前提としているが、観客が第１の役割のプレイヤーであってもよくかかる場合の端末の構成についても必要に応じて説明を加える。

配信者端末１００は、コンピュータであって、例えば、入出力制御、通信制御、そしてゲーム処理を行うプロセッサを含む。ここで、プロセッサは、典型的にはＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）および／またはＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であるが、マイコン、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、またはその他の汎用または専用のプロセッサなどであってもよい。

また、配信者端末１００は、かかる処理を実現するためにプロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータ、例えばユーザ入力（イベントデータ）、映像データ、ゲームデータ、などを一時的に格納するメモリを含んでいる。メモリは、かかるプログラム／データが展開されるワークエリアを有するＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を含み得る。

なお、配信者端末１００は、全てのデータをオンメモリの状態で扱ってもよいし、一部のデータが補助記憶装置に退避されていてもよい。補助記憶装置は、例えば、配信者端末１００に内蔵または外付けされたＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリなどであってもよいし、配信者端末１００からアクセス可能なデータベースサーバであってもよい。

また、配信者端末１００は、複数のコンピュータの組み合わせであってよい。例えば、配信者端末１００の機能部、例えば図２に示される機能部が別個のコンピュータに分散して実装されてもよい。

次に、図２を用いて配信者端末１００の構成例の説明を続ける。図２の配信者端末１００は、通信Ｉ／Ｆ（インタフェース） １０１と、入力装置１０２と、出力装置１０３と、受信データ取得部１１１と、デコーダ１１２と、映像データ記憶部１１３と、出力制御部１１４と、ユーザ入力取得部１１５と、送信制御部１１６と、遷移制御部１１７と、キャラクタ管理部１１８と、脱落者検出部１１９と、描画部１２０と、ゲームデータ記憶部１２１と、映像データ取得部１２２と、エンコーダ１２３とを含む。

通信Ｉ／Ｆ １０１は、ネットワーク経由で、外部装置、例えば、動画配信サーバ３００またはその他のサーバ、などと通信をするためのモジュールであり得る。例えば、通信Ｉ／Ｆ １０１は、Ｗｉ−Ｆｉモジュール、４Ｇモジュール、５Ｇモジュール、などの一部または全部を含み得る。通信Ｉ／Ｆ １０１は、配信者端末１００に内蔵されてもよいし、配信者端末１００に外付けされてもよい。

通信Ｉ／Ｆ １０１は、共通のライブ動画を再生する他の端末において取得された、ゲームに関するユーザ入力（イベントデータ）を動画配信サーバ３００からネットワーク経由で受信し、これを受信データ取得部１１１へ送る。なお、図２の例では、観客は全て第２の役割のプレイヤーであるので、かかるユーザ入力は、典型的にはゲームにおいてキャラクタの移動を制御するためのものであり得る。また、通信Ｉ／Ｆ １０１は、ライブ動画の映像データを動画配信サーバ３００からネットワーク経由で受信し、これを受信データ取得部１１１へ送ってもよい。なお、前述のように、配信者端末１００は、自ら作成したライブ動画の映像データを再生してもよい。この場合には、通信Ｉ／Ｆ １０１は映像データを動画配信サーバ３００から受信しない。代わりに、映像データ取得部１２２がエンコード前の映像データを映像データ記憶部１１３へ送るか、エンコーダ１２３がエンコード済みの映像データをデコーダ１１２へ送ることになる。

通信Ｉ／Ｆ １０１は、ユーザ入力取得部１１５によって取得された、ゲームに関するユーザ入力（イベントデータ）を送信制御部１１６から受け取り、これを動画配信サーバ３００へネットワーク経由で送信する。なお、図２の例では、配信者が第１の役割のプレイヤーであるので、かかるユーザ入力は、ゲームを第１のゲーム状態、例えばだるまが振り向いていない状態、から第２のゲーム状態、例えばだるまが振り向いた状態に遷移させるためのものであり得る。

さらに、通信Ｉ／Ｆ １０１は、ライブ動画のエンコードされた映像データを送信制御部１１６から受け取り、これを動画配信サーバ３００へネットワーク経由で送信する。なお、観客が第１の役割のプレイヤーである場合には、その観客端末の通信Ｉ／Ｆはかかる機能を必要としない。

入力装置１０２は、例えば、タッチスクリーン、キーボード、マウス、テンキー、マイクロフォン、カメラ、慣性センサ、などであり得る。入力装置１０２は、配信者端末１００に内蔵されてもよいし、配信者端末１００に外付けされてもよい。

入力装置１０２は、第１の役割のプレイヤーとしての配信者からゲームに関する操作、例えばタッチ、タップ、スワイプ、ドラグ、クリック、などを受け付け、これに応じたユーザ入力（イベントデータ）を発生する。そして、入力装置１０２は、このユーザ入力をユーザ入力取得部１１５へ送る。

また、例えば入力装置１０２としてのカメラは、配信者または他の被写体を撮影して映像データを生成する。そして、この入力装置１０２は、映像データを映像データ取得部１２２へ送る。かかる映像データは、特に限定されないが、例えば図３に示される配信者の自撮り映像であってもよい。なお、観客が第１の役割のプレイヤーである場合には、その観客端末の入力装置はかかる機能を必要としない。

出力装置１０３は、少なくともディスプレイを含み、このほかにスピーカ、バイブレータ、などを含んでもよい。出力装置１０３は、配信者端末１００に内蔵されてもよいし、配信者端末１００に外付けされてもよい。

出力装置１０３は、出力制御部１１４から映像データを受け取り、これを出力（表示）する。また、出力装置１０３は、出力制御部１１４から音声データを受け取ってこれを出力してもよい。

受信データ取得部１１１は、例えば前述のプロセッサに相当し得る。受信データ取得部１１１は、ライブ動画のエンコードされた映像データを通信Ｉ／Ｆ １０１から取得し、これをデコーダ１１２へ送る。また、受信データ取得部１１１は、このライブ動画を再生する他の端末において取得された、ゲームに関するユーザ入力、例えば当該ゲームにおいてキャラクタの移動を制御するためのユーザ入力、を通信Ｉ／Ｆ １０１から取得し、これをキャラクタ管理部１１８へ送る。

デコーダ１１２は、例えば前述のプロセッサまたは専用の回路に相当し得る。デコーダ１１２は、ライブ動画のエンコードされた映像データを受信データ取得部１１１から受け取る。デコーダ１１２は、エンコードされた映像データを適切なコーデックに従ってデコードして映像データを再生する。なお、デコーダ１１２は、ビデオデコーダに加えて音声デコーダを含んでいてもよい。デコーダ１１２は、再生した映像データを映像データ記憶部１１３に書き込む。

映像データ記憶部１１３は、例えば前述のメモリに相当し得る。映像データ記憶部１１３は、デコーダ１１２によって再生された、ライブ動画の映像データを保存する。ゲームの非プレイ時には、この映像データは、出力制御部１１４によって適時、すなわち当該映像データに対応する出力タイミングの到来前に、読み出される。他方、ゲームのプレイ時に、この映像データは、後述されるように、描画部１２０によってゲーム画面を重畳して更新される。そして、ゲーム画面が重畳された、ライブ動画の映像データは、出力制御部１１４によって適時に読み出される。

出力制御部１１４は、例えば前述のプロセッサに相当し得る。出力制御部１１４は、映像データ記憶部１１３に保存された映像データを適時に読み出し、これを出力装置１０３へ送る。

ユーザ入力取得部１１５は、例えば前述のプロセッサに相当し得る。ユーザ入力取得部１１５は、ゲームに関するユーザ入力、例えばゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力、を入力装置１０２から取得する。ユーザ入力取得部１１５は、このユーザ入力を送信制御部１１６および遷移制御部１１７へ送る。

送信制御部１１６は、例えば前述のプロセッサに相当し得る。送信制御部１１６は、ユーザ入力取得部１１５によって取得されたユーザ入力、例えばゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力、をユーザ入力取得部１１５から受け取り、これを通信Ｉ／Ｆ １０１へ送る。

また、送信制御部１１６は、ライブ動画のエンコードされた映像データをエンコーダ１２３から受け取り、これを通信Ｉ／Ｆ １０１へ送る。なお、観客が第１の役割のプレイヤーである場合には、その観客端末の送信制御部はかかる機能を必要としない。

遷移制御部１１７は、例えば前述のプロセッサに相当し得る。遷移制御部１１７は、ユーザ入力取得部１１５によって取得された、ゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力を受け取る。遷移制御部１１７は、このユーザ入力の履歴に基づいて、ゲームの第１のゲーム状態から第２のゲーム状態への遷移を制御する。遷移制御部１１７は、ゲームが第２のゲーム状態へ遷移すると、これをキャラクタ管理部１１８および描画部１２０に通知する。なお、第１の役割のプレイヤーが複数人存在する場合には、当該プレイヤーの端末からも、ゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力が受信され得る。この場合には、かかるユーザ入力は、受信データ取得部１１１から遷移制御部１１７へ送られ得る。

具体的には、遷移制御部１１７は、このユーザ入力の履歴に基づいて、第１のゲーム状態から第２のゲーム状態への遷移の進行度を算出し、この進行度が予め定められた値に到達するとゲームを第２のゲーム状態へ遷移させてもよい。

例えば、遷移制御部１１７は、ユーザ入力のなされた位置、回数、強度、持続時間、などに依存して、進行度を単位時間毎に再計算し得る。ここで、単位時間は、ゲームのフレーム時間であってよい。ゲームのフレーム時間は、ライブ動画のフレーム時間と同一であってもよいし、異なっていてもよい。例えば、ゲームのフレームレートをライブ動画のフレームレートよりも低くすることで、プレイヤー間の同期を容易にするとともに、配信者端末１００および観客端末２００における処理負荷を軽減できる。

なお、遷移制御部１１７は、進行度が予め定められた値に到達してからゲームを第２のゲーム状態へ遷移させるまでの間にディレイを設けてもよい。このディレイは、例えば人間の反応時間、通信の遅延時間、などに基づいて定められ得る。

また、遷移制御部１１７は、この進行度を描画部１２０へ送り、描画部１２０が第１の役割のプレイヤーに進行度を視覚的に把握させるための描画を行ってもよい。この具体例については後述する。

キャラクタ管理部１１８は、例えば前述のプロセッサに相当し得る。キャラクタ管理部１１８は、ゲームに登場するキャラクタの状態を管理する。なお、キャラクタ管理部１１８は、配信者端末１００が行うゲームの仕様次第では不要となり得る。

具体的には、キャラクタ管理部１１８は、受信データ取得部１１１から、ゲームにおいて各キャラクタの移動を制御するためのユーザ入力を受け取り、この履歴に基づいて当該キャラクタの現在位置または移動量を計算する。例えば、キャラクタ管理部１１８は、単位時間毎に各キャラクタの移動を制御するためのユーザ入力を受け取り、これに基づいて各キャラクタの移動の有無、または当該単位時間あたりの移動量を決定し、当該キャラクタの現在位置または移動量を更新し得る。キャラクタ管理部１１８は、描画対象となるキャラクタの状態を示すデータを描画部１２０へ送る。

また、キャラクタ管理部１１８は、遷移制御部１１７によりゲームが第２のゲーム状態へ遷移したことを通知されると、各キャラクタの移動を制御するためのユーザ入力を脱落者検出部１１９へ送る。そして、キャラクタ管理部１１８は、ゲームが第２のゲーム状態にある時に移動中であるキャラクタ、すなわち脱落者に該当するキャラクタを識別するデータ（例えば、識別子）を受け取る。キャラクタ管理部１１８は、受け取ったデータによって識別されるキャラクタの脱落者フラグを有効にする。キャラクタ管理部１１８は、脱落者フラグが有効であるキャラクタを描画対象から除外してもよいししなくてもよい。例えば、かかるキャラクタは、だるまの捕虜として描画されてもよい。

なお、キャラクタ管理部１１８は、描画対象となるキャラクタを例えばその総数が所定数（例えば２０人）以下になるように選定してもよい。これにより、ゲームの参加者数が所定数を超えて増えたとしても、ゲーム画面の描画負荷の増加を抑制できる。

描画対象となるキャラクタの選定は、例えばターン毎に行われ得る。故に、ターンの切り替わり時に、ゲーム画面中に描画されるキャラクタが追加、削除または変更されてもよい。ここで、ターンとは、例えば、だるまがキャラクタに背を向け（この状態を第３のゲーム状態と呼ぶこともできる）、だるまがかけ声を新たに唱え（第１のゲーム状態）、だるまが振り向き（第２のゲーム状態）、だるまがまたキャラクタに背を向ける（第３のゲーム状態）までのゲームサイクルを意味する。なお、第３のゲーム状態は、第１のゲーム状態と区別されてもよいし区別されなくてもよい。１ターンでゲームが終了しなければ、複数ターンに亘ってゲームは継続することになる。キャラクタ管理部１１８は、描画対象となるキャラクタをランダムに選定してもよいし、だるまに近い位置に居るキャラクタを優先的に選択してもよい。

さらに、キャラクタ管理部１１８は、全てのキャラクタが脱落者として検出された場合には、キャラクタの敗北、またはだるまの勝利を表現する演出画像の描画を描画部１２０に命令してもよい。他方、キャラクタ管理部１１８は、いずれかのキャラクタが予め定められた位置に到達し場合に、キャラクタの勝利、またはだるまの敗北を表現する演出画像の描画を描画部１２０に命令してもよい。

脱落者検出部１１９は、例えば前述のプロセッサに相当し得る。なお、脱落者検出部１１９は、配信者端末１００が行うゲームのルール次第では不要となり得る。脱落者検出部１１９は、ゲームが第２のゲーム状態に遷移すると、キャラクタ管理部１１８から各キャラクタの移動を制御するためのユーザ入力を受け取る。脱落者検出部１１９は、このユーザ入力に基づいて脱落者を検出し、脱落者に該当するキャラクタを識別するデータをキャラクタ管理部１１８に返す。脱落者検出部１１９は、例えば、ユーザ入力に基づいて決定される単位時間あたりの移動量が閾値（これは、０であってもよい）を超えたキャラクタを脱落者として検出し得る。

描画部１２０は、例えば前述のプロセッサに相当し得る。描画部１２０は、キャラクタ管理部１１８から描画対象となるキャラクタの状態を示すデータを受け取り、ゲームデータ記憶部１２１からゲームデータ、例えばキャラクタおよびだるまの素材データなど、を読み出す。描画部１２０は、単位時間毎に、映像データ記憶部１１３からリアルタイムコンテンツの映像データを読み出し、当該映像データに重畳してゲーム画面を描画する。

描画部１２０は、現在のゲーム状態に関わらず、ゲーム画面の一部として、第１の役割のプレイヤーのための種々のＵＩを描画し得る。例えば、描画部１２０は、遷移制御部１１７から受け取った進行度をスライダの位置によって表現するシークバーを描画してもよい。これにより、第１の役割のプレイヤーは、現在の進行度を視覚的に把握することができる。なお、このシークバーは、第１の役割のプレイヤーからスライダの位置を動かす操作に応じてゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力を発生させるためにも利用され得る。或いは、描画部１２０はボタンを描画してもよく、このボタンが第１の役割のプレイヤーが当該ボタンを選択する操作（例えば、タッチ、タップ、クリック、スワイプ、など）に応じてゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力を発生させるために利用されてもよい。なお、描画部１２０によって描画されたボタンの代わりに、入力装置１０２に含まれる物理ボタンがかかるユーザ入力を発生させるために利用されてもよい。

例えば、描画部１２０は、ゲームが第１のゲーム状態にある間は、描画対象のキャラクタのうち脱落者を除くキャラクタの描画位置を、当該キャラクタの現在位置（これは、このキャラクタの移動を制御する入力の履歴に依存して決まる）を示すデータに従って再描画する。

これにより、例えば図４に例示されるように、各キャラクタが対応するプレイヤーの操作に応じて移動するゲーム画面を演出することができる。図４のゲーム画面は、キャラクタおよびだるまの画像に加えて、第１の役割のプレイヤー用のＵＩとして、前述のシークバーを含む。これにより、第１の役割のプレイヤーは、現在の進行度を視覚的に把握することができる。また、このゲーム画面では、だるまが唱えるかけ声が記載されたテキスト表示部がシークバーと平行に配置されており、このテキストはスライダ位置を基準に左側と右側とで表示態様（例えばフォント、色など）が異なる。このテキストは、シークバー内の位置がかけ声のどの部分に対応するかを第１の役割のプレイヤーが把握するのに役立つ。他方、かかるシークバーおよびテキストは、ゲームの緊張感を保つために第２の役割のプレイヤーのＵＩからは省略されてよい。

また、図４のゲーム画面は、第１の役割のプレイヤーおよび第２の役割のプレイヤー共通のＵＩとして、だるまが唱えるかけ声のうち現在どの部分（文字または単語）を読み上げているかを示す吹き出しをさらに含む。これにより、第２の役割のプレイヤーも第１の役割のプレイヤーに比べて粗い精度ではあるものの、現在の進行度を視覚的に把握することができる。なお、吹き出しは一例に過ぎず、その他のテキストまたは画像に置き換えられてよいし、かけ声が音声で読みあげられてもよい。さらに、このゲーム画面は、キャラクタの目標地点となるゴールラインがキャラクタとだるまとの間に配置されている。これにより、第２の役割のプレイヤーがどこまで移動すれば勝利できるのかを理解できる。加えて、このゲーム画面は、ターン終了までの残り時間の表示部も含む。この残り時間が０になると、ターンが強制的に終了する（すなわち、ゲームが第１のゲーム状態から第３のゲーム状態に遷移する）。

さらに、図４のゲーム画面は、「フェイント」ボタンを含む。前述の第３のゲーム状態の間に、第１の役割のプレイヤーがこのボタンを選択する操作をすると、ゲームは第２のゲーム状態へ再遷移する。すなわち、移動中のキャラクタが脱落者に追加され得る。第２の役割のプレイヤーからすると、だるまが元の姿勢に復帰した後に、すぐに新たにかけ声を唱え始めるのか（第１のゲーム状態に遷移するのか）、それともフェイントを入れて振り向いてくるかが判らないので、リスクを取って移動すべきか否かの駆け引きを楽しむことができる。なお、第３のゲーム状態の間に、第１の役割のプレイヤーがシークバーをタップするなどの操作をすると、ゲームは第１のゲーム状態に遷移する。

そして、描画部１２０は、遷移制御部１１７によりゲームが第２のゲーム状態へ遷移したことを通知されると、例えば図５に例示されるように、だるまが振り向いた画像を含むゲーム画面を描画してもよい。また、描画部１２０は、描画対象のキャラクタのうち脱落者として検出されたキャラクタを、ゲーム画面から消去してもよいし、例えばだるまの捕虜として描画し続けてもよい。また、このゲーム画面では、前述のスライダはシークバーの終点（右端）に位置している。さらに、このゲーム画面では、かけ声の最後の文字である「だ」が読み上げられたことを示す吹き出しを含む。

さらに、描画部１２０は、キャラクタ管理部１１８からの命令に従って、前述のキャラクタの敗北、もしくはだるまの勝利を表現する演出画像、または前述のキャラクタの勝利、またはだるまの敗北を表現する演出画像を描画し得る。

ゲームデータ記憶部１２１は、例えば前述のメモリに相当し得る。ゲームデータ記憶部１２１は、ゲーム（アプリケーション）によって使用される種々のゲームデータを保存する。ゲームデータは、例えばゲーム画面の描画および出力音声を制御するために必要とされる素材データを含み得る。素材データは、例えば、キャラクタ、オブジェクト、背景、ビジュアルエフェクト（Ｖｉｓｕａｌ Ｅｆｆｅｃｔ）などの画像データ、効果音（ＳＥ：Ｓｏｕｎｄ Ｅｆｆｅｃｔ）、ＢＧＭ(Ｂａｃｋｇｒｏｕｎｄ Ｍｕｓｉｃ)、キャラクターボイス（Ｃｈａｒａｃｔｅｒ Ｖｏｉｃｅ）、などの音声データ、振動パターン、などであり得る。なお、後述される第２の実施形態では、配信者端末１００および観客端末２００は、ゲーム画面の描画／出力音声の制御を行わないので、素材データを保存しなくてもよい。ゲームデータは、ゲームの開始時にダウンロードされゲームデータ記憶部１２１に一時的に書き込まれてもよいし、ゲームのインストールまたはアップデート時にゲームデータ記憶部１２１に書き込まれ、または書き換えられ得る。ゲームデータは、描画部１２０によって読み出される。

映像データ取得部１２２は、例えば前述のプロセッサに相当し得る。ライブ動画の映像データを例えば入力装置１０２としてのカメラまたはその他の映像ソースから取得し、これをエンコーダ１２３へ送る。なお、観客が第１の役割のプレイヤーである場合には、その観客端末は映像データ取得部１２２に相当する機能部を必要としない。

エンコーダ１２３は、例えば前述のプロセッサまたは専用の回路に相当し得る。エンコーダ１２３は、ライブ動画の映像データを映像データ取得部１２２から受け取り、これを適切なコーデックに従ってエンコードする。そして、エンコーダ１２３は、ライブ動画のエンコードされた映像データを送信制御部１１６へ送る。なお、観客が第１の役割のプレイヤーである場合には、その観客端末はエンコーダ１２３に相当する機能部を必要としない。

次に、図６および図７を用いて、第２の役割のプレイヤーの端末としての観客端末２００の構成について詳しく説明する。観客端末２００は、コンピュータであって、配信者端末１００と同様のハードウェア構成、例えばプロセッサおよびメモリ、を有し得る。また、観客端末２００は、複数のコンピュータの組み合わせであってよい。例えば、観客端末２００の機能部、例えば図６に示される機能部が別個のコンピュータに分散して実装されてもよい。

次に、図６を用いて観客端末２００の構成例の説明を続ける。図６の観客端末２００は、通信Ｉ／Ｆ ２０１と、入力装置２０２と、出力装置２０３と、受信データ取得部２１１と、デコーダ２１２と、映像データ記憶部２１３と、出力制御部２１４と、ユーザ入力取得部２１５と、送信制御部２１６と、遷移制御部２１７と、キャラクタ管理部２１８と、脱落者検出部２１９と、描画部２２０と、ゲームデータ記憶部２２１とを含む。

図６の出力装置２０３、デコーダ２１２、映像データ記憶部２１３、出力制御部２１４、脱落者検出部２１９およびゲームデータ記憶部２２１はそれぞれ、図２の出力装置１０３、デコーダ１１２、映像データ記憶部１１３、出力制御部１１４、脱落者検出部１１９およびゲームデータ記憶部１２１と同一または類似の構成であってよいので説明を省略する。

通信Ｉ／Ｆ ２０１は、前述の通信Ｉ／Ｆ １０１と同様のハードウェアであり得る。通信Ｉ／Ｆ ２０１は、観客端末２００に内蔵されてもよいし、観客端末２００に外付けされてもよい。

通信Ｉ／Ｆ ２０１は、共通のライブ動画を再生する他の端末において取得された、ゲームに関するユーザ入力を動画配信サーバ３００からネットワーク経由で受信し、これを受信データ取得部２１１へ送る。なお、かかるユーザ入力は、ゲームにおいてキャラクタの移動を制御するためのものと、ゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのものとであり得る。また、通信Ｉ／Ｆ ２０１は、ライブ動画の映像データを動画配信サーバ３００からネットワーク経由で受信し、これを受信データ取得部２１１へ送る。

通信Ｉ／Ｆ ２０１は、ユーザ入力取得部２１５によって取得された、ゲームに関するユーザ入力を送信制御部２１６から受け取り、これを動画配信サーバ３００へネットワーク経由で送信する。なお、図６の例では、観客端末２００の操作者である観客は第２の役割のプレイヤーであるので、かかるユーザ入力は、当該観客に対応するキャラクタの移動を制御するためのものであり得る。

入力装置２０２は、前述の入力装置１０２と同様のハードウェアであり得る。入力装置２０２は、観客端末２００に内蔵されてもよいし、観客端末２００に外付けされてもよい。入力装置２０２は、第１の役割のプレイヤーとしての配信者からゲームに関する操作を受け付け、これに応じたユーザ入力を発生する。そして、入力装置２０２は、このユーザ入力をユーザ入力取得部２１５へ送る。

受信データ取得部２１１は、例えば前述のプロセッサに相当し得る。受信データ取得部２１１は、ライブ動画のエンコードされた映像データを通信Ｉ／Ｆ ２０１から取得し、これをデコーダ２１２へ送る。また、受信データ取得部２１１は、このライブ動画を再生する他の端末（第２の役割のプレイヤーの端末）において取得された、ゲームに関するユーザ入力、例えば当該ゲームにおいてキャラクタの移動を制御するためのユーザ入力、を通信Ｉ／Ｆ ２０１から取得し、これをキャラクタ管理部２１８へ送る。さらに、受信データ取得部２１１は、このライブ動画を再生する他の端末（第１の役割のプレイヤーの端末）において取得された、ゲームに関するユーザ入力、例えば当該ゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力、を通信Ｉ／Ｆ ２０１から取得し、これを遷移制御部２１７へ送る。

ユーザ入力取得部２１５は、例えば前述のプロセッサに相当し得る。ユーザ入力取得部２１５は、ゲームに関するユーザ入力、例えば観客端末２００の操作者に対応するキャラクタの移動を制御するためのユーザ入力、を入力装置２０２から取得する。ユーザ入力取得部２１５は、このユーザ入力を送信制御部２１６およびキャラクタ管理部２１８へ送る。

送信制御部２１６は、例えば前述のプロセッサに相当し得る。送信制御部２１６は、ユーザ入力取得部２１５によって取得されたユーザ入力、例えばゲームにおいてキャラクタの移動を制御するためのユーザ入力、をユーザ入力取得部２１５から受け取り、これを通信Ｉ／Ｆ ２０１へ送る。

遷移制御部２１７は、例えば前述のプロセッサに相当し得る。遷移制御部２１７は、ゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力を受信データ取得部２１１から受け取る。遷移制御部２１７は、このユーザ入力の履歴に基づいて、ゲームの第１のゲーム状態から第２のゲーム状態への遷移を制御する。遷移制御部２１７は、ゲームが第２のゲーム状態へ遷移すると、これをキャラクタ管理部２１８および描画部２２０に通知する。かかるユーザ入力の履歴に基づいて遷移制御部２１７によって行われる処理は、前述の遷移制御部１１７と同一または類似であってよい。

キャラクタ管理部２１８は、例えば前述のプロセッサに相当し得る。キャラクタ管理部２１８は、ゲームに登場するキャラクタの状態を管理する。なお、キャラクタ管理部２１８は、観客端末２００が行うゲームの仕様次第では不要となり得る。

具体的には、キャラクタ管理部２１８は、受信データ取得部２１１およびユーザ入力取得部２１５から、ゲームにおいて各キャラクタの移動を制御するためのユーザ入力を受け取り、この履歴に基づいて当該キャラクタの現在位置または移動量を計算する。ここで、キャラクタ管理部２１８によって行われる処理は、基本的に前述のキャラクタ管理部１１８と同一または類似であってよい。

ただし、オプションとして、キャラクタ管理部２１８は、観客端末２００の操作者に対応するキャラクタを、当該キャラクタが脱落者として検出されない限りは描画対象のキャラクタとして選定するようにしてもよい。これにより、ゲームの参加者数が所定数を超えて増えたとしても、ゲーム画面の描画負荷の増加を抑制しつつ各プレイヤーは自らのキャラクタの現在位置を視認しながらゲームをプレイすることが可能となる。

描画部２２０は、例えば前述のプロセッサに相当し得る。描画部２２０は、キャラクタ管理部２１８から描画対象となるキャラクタの状態を示すデータを受け取り、ゲームデータ記憶部２２１からゲームデータ、例えばキャラクタおよびだるまの素材データなど、を読み出す。描画部２２０は、単位時間毎に、映像データ記憶部２１３からリアルタイムコンテンツの映像データを読み出し、当該映像データに重畳してゲーム画面を描画する。

描画部２２０は、現在のゲーム状態に関わらず、ゲーム画面の一部として、第２の役割のプレイヤーのための種々のＵＩを描画し得る。例えば、描画部２２０は、図７に例示されるように「進む」ボタンを描画してもよく、このボタンが第２の役割のプレイヤーが当該ボタンを選択する操作（例えば、タッチ、タップ、クリップ、など）に応じて当該プレイヤーに対応するキャラクタの移動を制御するためのユーザ入力を発生させるために利用されてもよい。なお、描画部２２０によって描画されたボタンの代わりに、入力装置２０２に含まれる物理ボタンがかかるユーザ入力を発生させるために利用されてもよい。

例えば、描画部２２０は、ゲームが第１のゲーム状態にある間は、描画対象のキャラクタのうち脱落者を除くキャラクタの描画位置を、当該キャラクタの現在位置を示すデータに従って再描画する。

これにより、例えば図７に例示されるように、各キャラクタが対応するプレイヤーの操作に応じて移動するゲーム画面を演出することができる。図７のゲーム画面は、図４および図５のゲーム画面とは異なり、第１の役割のプレイヤー向けのＵＩ、例えば、シークバーおよびこれと平行に配置されたテキスト表示部、および「フェイント」ボタンを含まない。また、観客端末２００の操作者に対応するキャラクタと他の参加者に対応するキャラクタとを容易に区別できるようにするために、両者の表示態様を異ならせている。他方、図７のゲーム画面では、図４および図５のゲーム画面と同様に、第１の役割のプレイヤーおよび第２の役割のプレイヤー共通のＵＩ、例えば、吹き出しおよび残り時間の表示部を含む。

なお、観客は、ゲームに参加せずにゲームを視聴することもできる。かかる観客向けの観客端末２００は、当該観客自身からのゲームに関するユーザ入力を扱う必要がないので、前述のユーザ入力取得部２１５および送信制御部２１６の機能の一部または全部を必要としない。

また、配信者は、第２の役割のプレイヤーとしてゲームに参加してもよい。かかる配信者向けの配信者端末１００は、図２の機能部の一部を変形すればよい。例えば、受信データ取得部１１１は、第１の役割のプレイヤーの観客端末２００から受信された、ゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力を取得するので、これを遷移制御部１１７へ送ればよい。また、ユーザ入力取得部１１５は、配信者に対応するキャラクタの移動を制御するユーザ入力を取得するので、これをキャラクタ管理部１１８へ送ればよい。さらに、配信者は、ゲームに参加せずにゲームを視聴することもできる。かかる配信者向けの配信者端末１００は、当該配信者自身からのゲームに関するユーザ入力を扱う必要がないので、前述のユーザ入力取得部１１５および送信制御部１１６の機能の一部または全部を必要としない。

次に、図８を用いて、第１の役割のプレイヤーの端末としての配信者端末１００の動作を説明する。図８の動作は、ステップＳ４０１から開始する。

ステップＳ４０１において、キャラクタ管理部１１８および描画部１２０は、ターン開始処理を行う。具体的には、キャラクタ管理部１１８は、描画対象となるキャラクタを選定し、選定したキャラクタの状態を示すデータを描画部１２０へ送る。描画部１２０は、このデータに基づいてゲーム画面を描画する。ステップＳ４０１の後に、処理はステップＳ４０２へ進む。

ステップＳ４０２において、入力装置１０２およびユーザ入力取得部１１５は、例えばＵＩに含まれるシークバーへの操作に応じて、ゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力を取得し、送信制御部１１６および通信Ｉ／Ｆ １０１はこれを動画配信サーバ３００へ送信する。他方、通信Ｉ／Ｆ １０１および受信データ取得部１１１は、他の端末（第２の役割のプレイヤーの端末）において取得されたユーザ入力を受信する（ステップＳ４０３）。

遷移制御部１１７は、ステップＳ４０２において取得されたユーザ入力に基づいて、第１のゲーム状態から第２のゲーム状態への進行度を算出する（ステップＳ４０４）。遷移制御部１１７は、ステップＳ４０４において算出した進行度に基づいて、ゲームを第２のゲーム状態へ遷移させるか否かを決定する（ステップＳ４０５）。ゲームを第２のゲーム状態へ遷移させる場合には処理はステップＳ４１１へ進み、そうでなければ処理はステップＳ４０６へ進む。

ステップＳ４０６において、キャラクタ管理部１１８はステップＳ４０３において受信したユーザ入力に基づいて各キャラクタの現在位置を更新し、いずれかのキャラクタがゲームをクリアしたか否か、例えば予め定められたゴールラインに到達したキャラクタが存在するか否か、を判定する。いずれかのキャラクタがゲームをクリアしたと判定された場合には処理はステップＳ４０９へ進み、そうでなければ処理はステップＳ４０７へ進む。

ステップＳ４０７において、描画部１２０は、各キャラクタの現在位置に応じたゲーム画面を描画する。そして、出力制御部１１４および出力装置１０３はステップＳ４０７において描画された１単位時間分のゲーム画面が重畳されたライブ動画の映像データを出力する（ステップＳ４０８）。ステップＳ４０８の後に、処理はステップＳ４０２に戻る。

ステップＳ４０９において、描画部１２０は、キャラクタの勝利、またはだるまの敗北を表現する演出画像を含むゲーム画面を描画する。そして、出力制御部１１４および出力装置１０３はステップＳ４０９において描画された１単位時間分のゲーム画面が重畳されたライブ動画の映像データを出力する（ステップＳ４１０）。ステップＳ４１０の後に、図８の動作は終了する。

ステップＳ４１１において、脱落者検出部１１９はステップＳ４０２において受信されたユーザ入力に基づいて脱落者を検出する。次に、キャラクタ管理部１１８は、ステップＳ４１１の結果、全てのキャラクタが脱落者として検出されたか否かを判定する（ステップＳ４１２）。全員が脱落したならば処理はステップＳ４１５へ進み、そうでなければ処理はステップＳ４１３へ進む。

ステップＳ４１３において、描画部１２０は、例えばだるまが振り向いた画像を含むゲーム画面を描画する。そして、出力制御部１１４および出力装置１０３はステップＳ４１３において描画された１単位時間分のゲーム画面が重畳されたライブ動画の映像データを出力する（ステップＳ４１４）。ステップＳ４１４の後に、処理はステップＳ４０１に戻る。

ステップＳ４１５において、描画部１２０は、キャラクタの敗北、またはだるまの処理を表現する演出画像を含むゲーム画面を描画する。そして、出力制御部１１４および出力装置１０３はステップＳ４１５において描画された１単位時間分のゲーム画面が重畳されたライブ動画の映像データを出力する（ステップＳ４１６）。ステップＳ４１６の後に、図８の動作は終了する。

次に、図９を用いて、第２の役割のプレイヤーの端末としての観客端末２００の動作を説明する。なお、図９のステップＳ５０１、ステップＳ５０５、およびステップＳ５０７乃至ステップＳ５１６は、図８のステップＳ４０１、ステップＳ４０５、およびステップＳ４０７乃至ステップＳ４１６とそれぞれ同一または類似の処理であってよいので説明を省略する。

ステップＳ５０２において、入力装置２０２およびユーザ入力取得部２１５は、例えばＵＩに含まれる「進む」ボタンへの操作に応じて、この観客端末２００の操作者に対応するキャラクタの移動を制御するためのユーザ入力を取得し、送信制御部２１６および通信Ｉ／Ｆ ２０１はこれを動画配信サーバ３００へ送信する。他方、通信Ｉ／Ｆ ２０１および受信データ取得部２１１は、他の端末（第１の役割のプレイヤーの端末または第２の役割のプレイヤーの端末）において取得されたユーザ入力を受信する（ステップＳ５０３）。

遷移制御部２１７は、ステップＳ５０３において受信された、ゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力に基づいて、第１のゲーム状態から第２のゲーム状態への進行度を算出する（ステップＳ５０４）。

ステップＳ５０６において、キャラクタ管理部２１８は、ステップＳ５０２において取得したユーザ入力と、ステップＳ５０３において受信した、キャラクタの移動を制御するためのユーザ入力とに基づいて各キャラクタの現在位置を更新し、いずれかのキャラクタがゲームをクリアしたか否かを判定する。いずれかのキャラクタがゲームをクリアしたと判定された場合には処理はステップＳ５０９へ進み、そうでなければ処理はステップＳ５０７へ進む。

以上説明したように、第１の実施形態に係る端末は、リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームに関するユーザ入力を取得し、当該リアルタイムコンテンツを再生中の他の端末へサーバを介して送信する。そして、各端末は、自ら取得したユーザ入力および／またはサーバを介して受信したユーザ入力に基づいて、ゲーム状態の遷移を制御し、ゲーム状態に応じたゲーム画面をリアルタイムコンテンツの映像データに重畳して描画する。故に、この端末によれば、リアルタイムコンテンツの配信者および視聴者が、当該リアルコンテンツと共に楽しむことのできるゲーム体験を提供することができる。

さらに、第１の役割のプレイヤーの端末は、当該プレイヤーのＵＩとして、ゲーム状態の遷移の進行度を表示するＧＵＩ部品、例えばシークバー、などを含み得る。これにより、第１の役割のプレイヤーは、ゲーム状態の遷移の進行の速さなどを直感的に操ることができる。

なお、本実施形態において、サーバは、ゲームのプレイヤーの端末から受信したユーザ入力を全てそのままプレイヤーおよび視聴者の端末へ送信することを前提に説明したが、これは一例に過ぎない。サーバは、受信したユーザ入力の一部をフィルタリング、例えば破棄、してから各端末へ送信してもよいし、受信したユーザ入力の一部または全部を要約してから各端末へ送信してもよい。ここで、要約とは、例えばサーバがあるキャラクタを単位距離移動させるユーザ入力を３回受信した場合に、これをあるキャラクタを３単位距離移動させる１つのユーザ入力に変換する処理、などであり得る。サーバは、かかるフィルタリングおよび／または要約を、定常的に行ってもよいし、対象となるゲームに関わるデータ通信量が閾値を超えている場合、などの条件付きで行ってもよい。

（第２の実施形態）
第２の実施形態では、動画配信サーバ３００が、各端末からユーザ入力を受信し、ゲーム処理を集中的に行う。故に、配信者端末１００および観客端末２００は、ゲームに関するユーザ入力を取得し、動画配信サーバ３００へ送信する以外の機能を必要としない。故に、配信者端末１００から、図２の遷移制御部１１７、キャラクタ管理部１１８、脱落者検出部１１９、描画部１２０およびゲームデータ記憶部１２１は省略され得る。同様に、観客端末２００から図６の遷移制御部２１７、キャラクタ管理部２１８、脱落者検出部２１９、描画部２２０およびゲームデータ記憶部２２１は省略され得る。

次に、図１０を用いて、第２の実施形態に係る動画配信サーバ３００の構成について詳しく説明する。

動画配信サーバ３００は、コンピュータであって、配信者端末１００および／または観客端末２００と同様のハードウェア構成、例えばプロセッサおよびメモリ、を有し得る。また、動画配信サーバ３００は、複数のコンピュータの組み合わせであってよい。例えば、動画配信サーバ３００の機能部、例えば図１０に示される機能部が別個のコンピュータに分散して実装されてもよい。

次に、図１０を用いて動画配信サーバ３００の構成例の説明を続ける。図１０の動画配信サーバ３００は、通信Ｉ／Ｆ ３０１と、受信データ取得部３１１と、デコーダ３１２と、映像データ記憶部３１３と、送信制御部３１６と、遷移制御部３１７と、キャラクタ管理部３１８と、脱落者検出部３１９と、描画部３２０と、ゲームデータ記憶部３２１と、エンコーダ３２３とを含む。

図１０のデコーダ３１２、遷移制御部３１７、脱落者検出部３１９およびゲームデータ記憶部３２１は、それぞれ図６のデコーダ２１２、遷移制御部２１７、脱落者検出部２１９およびゲームデータ記憶部２２１と同一または類似の構成であってよいので説明を省略する。

通信Ｉ／Ｆ ３０１は、前述の通信Ｉ／Ｆ １０１および／または通信Ｉ／Ｆ ２０１と同様のハードウェアであり得る。通信Ｉ／Ｆ ３０１は、動画配信サーバ３００に内蔵されてもよいし、動画配信サーバ３００に外付けされてもよい。

通信Ｉ／Ｆ ３０１は、共通のライブ動画を再生する各端末において取得された、ゲームに関するユーザ入力を動画配信サーバ３００からネットワーク経由で受信し、これを受信データ取得部３１１へ送る。なお、かかるユーザ入力は、ゲームにおいてキャラクタの移動を制御するためのものと、ゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのものとであり得る。また、通信Ｉ／Ｆ ３０１は、ライブ動画の映像データを配信者端末１００からネットワーク経由で受信し、これを受信データ取得部３１１へ送ってもよい。

通信Ｉ／Ｆ ３０１は、ライブ動画のエンコードされた映像データを送信制御部３１６から受け取り、これを当該ライブ動画を再生中の各端末へネットワーク経由で送信する。ゲームのプレイ時には、この映像データには描画部３２０によってゲーム画面が重畳されている。

受信データ取得部３１１は、例えば前述のプロセッサに相当し得る。受信データ取得部３１１は、ライブ動画のエンコードされた映像データを通信Ｉ／Ｆ ３０１から取得し、これをデコーダ３１２へ送る。また、受信データ取得部３１１は、このライブ動画を再生する各端末（第２の役割のプレイヤーの端末）において取得された、ゲームに関するユーザ入力、例えば当該ゲームにおいてキャラクタの移動を制御するためのユーザ入力、を通信Ｉ／Ｆ ３０１から取得し、これをキャラクタ管理部３１８へ送る。さらに、受信データ取得部３１１は、このライブ動画を再生する配信者端末１００または観客端末２００（第１の役割のプレイヤーの端末）において取得された、ゲームに関するユーザ入力、例えば当該ゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力、を通信Ｉ／Ｆ ３０１から取得し、これを遷移制御部３１７へ送る。

映像データ記憶部３１３は、例えば前述のメモリに相当し得る。映像データ記憶部３１３は、デコーダ３１２によって再生された、ライブ動画の映像データを保存する。ゲームの非プレイ時には、この映像データは、エンコーダ３２３によって適時、すなわち当該映像データに対応する送信タイミングの到来前に、読み出される。他方、ゲームのプレイ時に、この映像データは、後述されるように、描画部３２０によってゲーム画面を重畳して更新される。そして、ゲーム画面が重畳された、ライブ動画の映像データは、エンコーダ３２３によって適時に読み出される。

送信制御部３１６は、ライブ動画のエンコードされた映像データをエンコーダ３２３から受け取り、これを通信Ｉ／Ｆ ３０１へ送る。前述のように、ゲームのプレイ時には、この映像データには描画部３２０によってゲーム画面が重畳されている。

キャラクタ管理部３１８は、例えば前述のプロセッサに相当し得る。キャラクタ管理部３１８は、ゲームに登場するキャラクタの状態を管理する。なお、キャラクタ管理部３１８は、観客端末２００が行うゲームの仕様次第では不要となり得る。

具体的には、キャラクタ管理部３１８は、受信データ取得部３１１から、ゲームにおいて各キャラクタの移動を制御するためのユーザ入力を受け取り、この履歴に基づいて当該キャラクタの現在位置または移動量を計算する。ここで、キャラクタ管理部３１８によって行われる処理は、基本的に前述のキャラクタ管理部１１８またはキャラクタ管理部２１８と同一または類似であってよい。

描画部３２０は、例えば前述のプロセッサに相当し得る。描画部３２０は、キャラクタ管理部３１８から描画対象となるキャラクタの状態を示すデータを受け取り、ゲームデータ記憶部３２１からゲームデータ、例えばキャラクタおよびだるまの素材データなど、を読み出す。描画部３２０は、単位時間毎に、映像データ記憶部３１３からリアルタイムコンテンツの映像データを読み出し、当該映像データに重畳してゲーム画面を描画する。

なお、前述のように、第１の役割のプレイヤーと第２の役割のプレイヤーとでＵＩは異なり得る。故に、描画部３２０は、各プレイヤー共通のゲーム画面を描画し、プレイヤー間で異なるＵＩ部分は各端末において描画されてもよい。或いは、動画配信サーバ３００は、第１の役割のプレイヤー用の映像データと、第２の役割のプレイヤー用の映像データとを並列的に描画し、配信してもよい。

エンコーダ３２３は、例えば前述のプロセッサまたは専用の回路に相当し得る。エンコーダ３２３は、映像データ記憶部３１３に保存された映像データを適時に読み出し、これを適切なコーデックに従ってエンコードする。そして、エンコーダ３２３は、ライブ動画のエンコードされた映像データを送信制御部３１６へ送る。

次に、図１１を用いて、動画配信サーバ３００の動作を説明する。なお、図１１のステップＳ６０５、ステップＳ６０７、ステップＳ６０９、ステップＳ６１１乃至ステップＳ６１３およびステップＳ６１５は、図８のステップＳ４０５、ステップＳ４０７、ステップＳ４０９、ステップＳ４１１乃至ステップＳ４１３およびステップＳ４１５とそれぞれ同一または類似の処理であってよいので説明を省略する。

図１１の動作は、ステップＳ６０１から開始する。ステップＳ６０１において、キャラクタ管理部３１８および描画部３２０は、ターン開始処理を行う。ステップＳ６０１の後に、処理はステップＳ６０３へ進む。

ステップＳ６０３において、通信Ｉ／Ｆ ３０１および受信データ取得部３１１は、各端末において取得されたユーザ入力を受信する。

遷移制御部３１７は、ステップＳ６０３において受信された、ゲームを第１のゲーム状態から第２のゲーム状態に遷移させるためのユーザ入力に基づいて、第１のゲーム状態から第２のゲーム状態への進行度を算出する（ステップＳ６０４）。

ステップＳ６０６において、キャラクタ管理部３１８は、ステップＳ６０３において受信した、キャラクタの移動を制御するためのユーザ入力に基づいて各キャラクタの現在位置を更新し、いずれかのキャラクタがゲームをクリアしたか否かを判定する。いずれかのキャラクタがゲームをクリアしたと判定された場合には処理はステップＳ６０９へ進み、そうでなければ処理はステップＳ６０７へ進む。

ステップＳ６０８において、エンコーダ３２３は、ステップＳ６０７において描画されたゲーム画面が重畳されたライブ動画の映像データをエンコードし、送信制御部３１６および通信Ｉ／Ｆ ３０１はこれを各端末へ送信する。ステップＳ６０８の後に、処理はステップＳ６０３に戻る。

ステップＳ６１０において、エンコーダ３２３は、ステップＳ６０９において描画されたゲーム画面が重畳されたライブ動画の映像データをエンコードし、送信制御部３１６および通信Ｉ／Ｆ ３０１はこれを各端末へ送信する。ステップＳ６１０の後に、図１１の動作は終了する。

ステップＳ６１４において、エンコーダ３２３は、ステップＳ６１３において描画されたゲーム画面が重畳されたライブ動画の映像データをエンコードし、送信制御部３１６および通信Ｉ／Ｆ ３０１はこれを各端末へ送信する。ステップＳ６１４の後に、処理はステップＳ６０１に戻る。

ステップＳ６１６において、エンコーダ３２３は、ステップＳ６１３において描画されたゲーム画面が重畳されたライブ動画の映像データをエンコードし、送信制御部３１６および通信Ｉ／Ｆ ３０１はこれを各端末へ送信する。ステップＳ６１６の後に、図１１の動作は終了する。

以上説明したように、第２の実施形態に係るサーバは、リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームに関するユーザ入力を当該ゲームの参加者の各端末から受信する。そして、このサーバは、受信したユーザ入力に基づいて、ゲーム状態の遷移を制御し、ゲーム状態に応じたゲーム画面をリアルタイムコンテンツの映像データに重畳して描画する。それから、このサーバは、ゲーム画面を重畳した、リアルタイムコンテンツの映像データを、当該リアルタイムコンテンツを再生中の各端末へ送信する。故に、このサーバによれば、リアルタイムコンテンツの配信者および視聴者が、当該リアルコンテンツと共に楽しむことのできるゲーム体験を提供することができる。

また、本実施形態において、サーバは必ずしも全てのゲーム処理を担当せずともよく、サーバおよび端末は必要に応じてゲーム処理を分担してもよい。具体的には、サーバは、ユーザ入力の処理、例えば、ゲーム状態の制御、キャラクタの状態の管理、脱落者の検出、その他の判定処理、など、を行い、描画に必要なデータを生成して端末に送信してもよい。そして、端末は、サーバから受信したデータに基づいて、残りの処理、例えば描画処理、を行ってもよい。この場合に、動画配信サーバ３００は、遷移制御部３１７、キャラクタ管理部３１８、および脱落者検出部３１９を備える必要があるものの、描画部３２０を備えなくてもよい。他方、配信者端末１００は、描画部１２０を備える必要があるものの、遷移制御部１１７、キャラクタ管理部１１８、および脱落者検出部１１９を備えなくてもよい。同様に、観客端末２００は、描画部２２０を備える必要があるものの、遷移制御部２１７、キャラクタ管理部２１８、および脱落者検出部２１９を備えなくてもよい。

（変形例）
実施形態の説明では、ゲーム画面およびリアルタイムコンテンツが２Ｄ映像であることとした。しかしながら、これらは、３Ｄ映像であってもよい。例えば、ＶＲ、ＡＲまたはＭＲ（Ｍｉｘｅｄ Ｒｅａｌｉｔｙ）などの３次元空間に、２次元または３次元のゲーム画面が描画されてもよい。

また、実施形態の説明では、ライブ動画の配信時に実行されるリアルタイムゲームについて説明したが、ライブ動画以外のコンテンツ、例えば、予め作成され動画配信サーバに保存されている動画の映像データの再生時に、当該動画の観客がかかるゲームを実行できるようにしてもよい。

また、実施形態の説明では、ライブ動画の配信時に起動可能なリアルタイムゲームを主に説明した。しかしながら、例えば前述のシークバーなどの第１の役割のプレイヤーのＵＩは、リアルタイムコンテンツに付随する様々な対象の状態を直感的に操るためのユーザ入力を受け付ける汎用ＵＩとしても応用可能である。

この場合に、端末または動画配信サーバは、かかるユーザ入力のなされる度に、その画面内位置、例えばスライダの位置、に基づいて、対象の状態を決定する状態制御部を備えていてもよい。この状態制御部は、例えばプロセッサに相当し得る。また、これらの端末または動画配信サーバにおいて、描画部は、決定された状態に応じて、対象を単位時間毎にリアルタイムコンテンツの映像データに重畳して再描画してもよい。

具体的には、リアルタイムコンテンツ、例えば仮想空間のライブ動画、に含まれる仮想オブジェクト、例えば、アバター、動物、ロボット、乗り物、などの状態、例えば、速度、加速度、姿勢、位置、などを制御するために、このＵＩが使用されてもよい。

また、リアルタイムコンテンツとともに再生可能なコンテンツ、例えば、ライブ動画において引用された他の非ライブ動画、などの状態、例えば、再生位置、再生速度、コマ送り位置、コマ送り速度、などを制御するためにこのＵＩが使用されてもよい。

なお、ＵＩは、シークバーのような１次元の位置情報を扱うものに限られず、２次元以上の位置情報を扱うものであってもよい。例えば、ある２次元位置を指定するユーザ入力がなされた場合に、Ｘ座標に基づいて対象の速度を制御し、Ｙ座標に基づいて対象の加速度を制御してもよい。

上述の実施形態は、本発明の概念の理解を助けるための具体例を示しているに過ぎず、本発明の範囲を限定することを意図されていない。実施形態は、本発明の要旨を逸脱しない範囲で、様々な構成要素の付加、削除または転換をすることができる。

上述の実施形態では、いくつかの機能部を説明したが、これらは各機能部の実装の一例に過ぎない。例えば、１つの装置に実装されると説明された複数の機能部が複数の別々の装置に亘って実装されることもあり得るし、逆に複数の別々の装置に亘って実装されると説明された機能部が１つの装置に実装されることもあり得る。

上記各実施形態において説明された種々の機能部は、回路を用いることで実現されてもよい。回路は、特定の機能を実現する専用回路であってもよいし、プロセッサのような汎用回路であってもよい。

上記各実施形態の処理の少なくとも一部は、例えば汎用のコンピュータに搭載されたプロセッサを基本ハードウェアとして用いることでも実現可能である。上記処理を実現するプログラムは、コンピュータで読み取り可能な記録媒体に格納して提供されてもよい。プログラムは、インストール可能な形式のファイルまたは実行可能な形式のファイルとして記録媒体に記憶される。記録媒体としては、磁気ディスク、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ等）、光磁気ディスク（ＭＯ等）、半導体メモリなどである。記録媒体は、プログラムを記憶でき、かつ、コンピュータが読み取り可能であれば、何れであってもよい。また、上記処理を実現するプログラムを、インターネットなどのネットワークに接続されたコンピュータ（サーバ）上に格納し、ネットワーク経由でコンピュータ（クライアント）にダウンロードさせてもよい。

１００・・・配信者端末
１０１，２０１，３０１・・・通信Ｉ／Ｆ
１０２，２０２・・・入力装置
１０３，２０３・・・出力装置
１１１，２１１，３１１・・・受信データ取得部
１１２，２１２，３１２・・・デコーダ
１１３，２１３，３１３・・・映像データ記憶部
１１４，２１４・・・出力制御部
１１５，２１５・・・ユーザ入力取得部
１１６，２１６，３１６・・・送信制御部
１１７，２１７，３１７・・・遷移制御部
１１８，２１８，３１８・・・キャラクタ管理部
１１９，２１９，３１９・・・脱落者検出部
１２０，２２０，３２０・・・描画部
１２１，２２１，３２１・・・ゲームデータ記憶部
１２２・・・映像データ取得部
１２３，３２３・・・エンコーダ
２００・・・観客端末
３００・・・動画配信サーバ

Claims (11)

1. リアルタイムコンテンツを再生可能な端末であって、
   前記リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームを第１のゲーム状態から第２のゲーム状態に遷移させるための第１のユーザ入力を取得する取得部と、
   前記第１のユーザ入力をサーバへ送信する送信部と、
   前記リアルタイムコンテンツを再生する１以上の他の端末によって取得された、前記リアルタイムゲームにおいてキャラクタの移動を制御するための第２のユーザ入力を前記サーバから受信する受信部と、
   前記第１のユーザ入力の履歴に基づいて、前記リアルタイムゲームの前記第１のゲーム状態から前記第２のゲーム状態への遷移を制御する遷移制御部と、
   前記キャラクタのうち前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるキャラクタを前記第２のユーザ入力に基づいて検出する検出部と、
   前記リアルタイムゲームが前記第１のゲーム状態にある間に、前記キャラクタのうち前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるとして検出されなかったキャラクタを、前記第２のユーザ入力の履歴に依存して決まる位置に、前記サーバから受信され、または前記端末によって作成された前記リアルタイムコンテンツの映像データに単位時間毎に重畳して再描画する描画部と
   を具備する、端末。
2. 前記遷移制御部は、前記第１のユーザ入力の履歴に基づいて、前記第１のゲーム状態から前記第２のゲーム状態への遷移の進行度を算出し、
   前記描画部は、前記進行度を表示するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）部品をさらに描画する、
   請求項１に記載の端末。
3. 前記ＧＵＩ部品は、前記進行度をスライダの位置によって表現するシークバーであって、
   前記第１のユーザ入力は、前記スライダの位置を動かす操作である、
   請求項２に記載の端末。
4. 前記第１のユーザ入力は、前記端末に備えられた物理ボタン、または前記描画部によって描画されたボタンを選択する操作であって、
   前記遷移制御部は、前記第１のユーザ入力が行われた持続時間を前記第１のゲーム状態から前記第２のゲーム状態への遷移の進行度としてカウントし、
   前記描画部は、前記進行度を表すテキストまたは画像をさらに描画する、
   請求項１に記載の端末。
5. 前記描画部は、前記キャラクタの全てが前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるとして検出された場合に、前記キャラクタが敗北したことを示す画像を描画する、請求項１に記載の端末。
6. 前記描画部は、前記キャラクタのいずれかが予め定められた位置に到達した場合に、当該キャラクタが勝利したことを示す画像を描画する、請求項１に記載の端末。
7. リアルタイムコンテンツを再生可能な端末であって、
   前記リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームにおいて第１のキャラクタの移動を制御するための第１のユーザ入力を取得する取得部と、
   前記第１のユーザ入力をサーバへ送信する送信部と、
   前記リアルタイムコンテンツを再生する１以上の第１の端末によって取得された、前記リアルタイムゲームにおいて前記第１のキャラクタとは異なる１以上の第２のキャラクタの移動を制御するための第２のユーザ入力と、前記リアルタイムコンテンツを再生する第２の端末によって取得された、前記リアルタイムゲームを第１のゲーム状態から第２のゲーム状態へ遷移させるための第３のユーザ入力とを前記サーバから受信する受信部と、
   前記第３のユーザ入力の履歴に基づいて、前記リアルタイムゲームの前記第１のゲーム状態から前記第２のゲーム状態への遷移を制御する遷移制御部と、
   前記第１のキャラクタおよび前記第２のキャラクタのうち前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるキャラクタを前記第１のユーザ入力および前記第２のユーザ入力に基づいて検出する検出部と、
   前記リアルタイムゲームが前記第１のゲーム状態にある間に、前記第１のキャラクタおよび前記第２のキャラクタのうち前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるとして検出されていないキャラクタを、前記第１のユーザ入力の履歴および前記第２のユーザ入力の履歴に依存して決まる位置に、前記サーバから受信され、または前記端末によって作成された前記リアルタイムコンテンツの映像データに単位時間毎に重畳して再描画する描画部と
   を具備する、端末。
8. リアルタイムコンテンツを再生可能な端末であって、
   前記リアルタイムコンテンツを再生する第１の端末によって取得された、前記リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームを第１のゲーム状態から第２のゲーム状態へ遷移させるための第１のユーザ入力と、前記リアルタイムコンテンツを再生する１以上の第２の端末によって取得された、前記リアルタイムゲームにおいてキャラクタの移動を制御するための第２のユーザ入力とをサーバから受信する受信部と、
   前記第１のユーザ入力の履歴に基づいて、前記リアルタイムゲームの前記第１のゲーム状態から前記第２のゲーム状態への遷移を制御する遷移制御部と、
   前記キャラクタのうち前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるキャラクタを前記第２のユーザ入力に基づいて検出する検出部と、
   前記リアルタイムゲームが前記第１のゲーム状態にある間に、前記キャラクタのうち前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるとして検出されていないキャラクタを、前記第２のユーザ入力の履歴に依存して決まる位置に、前記サーバから受信され、または前記端末によって作成された前記リアルタイムコンテンツの映像データに単位時間毎に重畳して再描画する描画部と
   を具備する、端末。
9. リアルタイムコンテンツを配信可能なサーバであって、
   前記リアルタイムコンテンツの映像データを前記リアルタイムコンテンツのソースとなる第１の端末から受信し、前記リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームを第１のゲーム状態から第２のゲーム状態へ遷移させるための第１のユーザ入力を前記リアルタイムコンテンツを再生する第２の端末から受信し、キャラクタの移動を制御するための第２のユーザ入力を前記リアルタイムコンテンツを再生する１以上の第３の端末から受信する受信部と、
   前記第１のユーザ入力の履歴に基づいて、前記リアルタイムゲームの前記第１のゲーム状態から前記第２のゲーム状態への遷移を制御する遷移制御部と、
   前記キャラクタのうち前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるキャラクタを前記第２のユーザ入力に基づいて検出する検出部と、
   前記リアルタイムゲームが前記第１のゲーム状態にある間に、前記キャラクタのうち前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるとして検出されていないキャラクタを、前記第２のユーザ入力の履歴に依存して決まる位置に、単位時間毎に前記リアルタイムコンテンツの映像データに重畳して再描画する描画部と、
   再描画された前記キャラクタを重畳した前記リアルタイムコンテンツの映像データを前記第１の端末、前記第２の端末および前記第３の端末へ送信する送信部と
   を具備する、サーバ。
10. リアルタイムコンテンツを配信可能なサーバであって、
    前記リアルタイムコンテンツの映像データを前記リアルタイムコンテンツのソースとなる第１の端末から受信し、前記リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームを第１のゲーム状態から第２のゲーム状態へ遷移させるための第１のユーザ入力を前記リアルタイムコンテンツを再生する第２の端末から受信し、キャラクタの移動を制御するための第２のユーザ入力を前記リアルタイムコンテンツを再生する１以上の第３の端末から受信する受信部と、
    前記第１のユーザ入力の履歴に基づいて、前記リアルタイムゲームの前記第１のゲーム状態から前記第２のゲーム状態への遷移を制御する遷移制御部と、
    前記第２のユーザ入力の履歴に基づいて、前記キャラクタの位置を管理する管理部と、
    前記キャラクタのうち前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるキャラクタを前記第２のユーザ入力に基づいて検出する検出部と、
    （ａ）前記リアルタイムコンテンツの映像データと、前記キャラクタの位置を示すデータと、前記キャラクタのうち前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるとして検出されたキャラクタを示すデータとを前記第１の端末、前記第２の端末および前記第３の端末へ送信し、（ｂ）前記リアルタイムゲームの前記第１のゲーム状態から前記第２のゲーム状態へ遷移する時に、前記リアルタイムゲームが前記第２のゲーム状態に遷移したことの通知を前記第１の端末、前記第２の端末および前記第３の端末へ送信する送信部と
    を具備する、サーバ。
11. リアルタイムコンテンツを再生可能な端末を、
    前記リアルタイムコンテンツの配信時に起動可能なリアルタイムゲームを第１のゲーム状態から第２のゲーム状態に遷移させるための第１のユーザ入力を取得する手段、
    前記第１のユーザ入力をサーバへ送信する手段、
    前記リアルタイムコンテンツの映像データと、前記リアルタイムコンテンツを再生する１以上の他の端末によって取得された、前記リアルタイムゲームにおいてキャラクタの移動を制御するための第２のユーザ入力を前記サーバから受信する手段、
    前記第１のユーザ入力の履歴に基づいて、前記リアルタイムゲームの前記第１のゲーム状態から前記第２のゲーム状態への遷移を制御する手段、
    前記キャラクタのうち前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるキャラクタを前記第２のユーザ入力に基づいて検出する手段、
    前記リアルタイムゲームが前記第１のゲーム状態にある間に、前記キャラクタのうち前記リアルタイムゲームが前記第２のゲーム状態にある時に移動中であるとして検出されなかったキャラクタを、前記第２のユーザ入力の履歴に依存して決まる位置に、前記サーバから受信され、または前記端末によって作成された前記リアルタイムコンテンツの映像データに単位時間毎に重畳して再描画する手段
    として機能させるプログラム。