JP2019146956A - ゲーム実行装置およびゲームプログラム - Google Patents

Abstract

【課題】イベントの発生が短期間に集中した場合にその通知に伴う悪影響を回避する。【解決手段】本発明の一態様によれば、ゲーム実行装置は、受信部と、イベント制御部と、選択部と、生成部とを含む。受信部は、ゲームのリアルタイムプレイ動画の観客の端末によって発行された当該ゲームに対する介入の実施要求を受信する補助サーバから、当該実施要求に基づくイベントの発生要求を受信する。イベント制御部は、少なくとも発生要求に応じて、ゲーム上で発生するイベントを制御する。選択部は、第１の期間内にゲーム上で発生する第１のイベントのうち所定個数を上限に通知対象イベントを選択する。生成部は、通知対象イベントの発生をゲームのプレイヤに通知する通知データを生成する。【選択図】 図２

Description

本発明は、双方向的なゲーム体験を提供するゲームの実行装置またはプログラムに関する。

ビデオゲームは、スタンドアローン（Ｓｔａｎｄ Ａｌｏｎｅ）型、またはオンラインゲーム（例えば、クラウドゲーム、ＭＯ（Ｍｕｌｔｉｐｌａｙｅｒ Ｏｎｌｉｎｅ）ゲーム、ＭＭＯ（Ｍａｓｓｉｖｅｌｙ Ｍｕｌｔｉｐｌａｙｅｒ Ｏｎｌｉｎｅ）ゲーム）に大別することができる。また、オンラインゲームは、Ｃ／Ｓ（Ｃｌｉｅｎｔ ／ Ｓｅｒｖｅｒ）型およびＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）型にさらに分類することができる。スタンドアローン型のゲームおよびＰ２Ｐ型のオンラインゲームは、プレイヤの端末がゲームプログラムを実行することで実現され、１人ないし高々数十人程度のプレイヤがプレイする。他方、特にＣ／Ｓ型では、プレイヤの端末に接続されたゲームサーバがゲームプログラムの少なくとも一部を実行することで実現され、ＭＭＯ型のゲームでは数百人から数百万人ものプレイヤがネットワークに同時接続してプレイすることができる。

ビデオゲームの基本的な仕組みは、プレイヤが、ゲームプログラムの出力であるゲーム画面、音声、振動などを認知し、これに基づいて判断を行って操作を入力し、ゲームプログラムがその操作に基づいてゲーム状態を遷移させてさらなる出力を生成する、というプレイヤ−ゲームプログラム間のやり取りの繰り返しである。

近年、動画共有システムでは、ゲーム実況生放送と呼ばれるジャンルの動画が台頭しつつある。ゲーム実況生放送とは、プレイヤ（配信者）が、ゲームをリアルタイムにプレイする様子を、多数の観客へ生放送（配信）する形態のコンテンツ共有法である。ゲーム実況生放送によれば、プレイヤ以外の観客も、ゲームを擬似的に体験して楽しむことができる。

さらに、一部の動画共有システムでは、生放送の動画に対して観客がコメントを付けることができる。ゲーム実況生放送において、観客が付けたコメントは、他の観客に加えて配信者もリアルタイムに閲覧することができる。配信者が観客からの助言コメントまたはリクエストコメントに応じたプレイをし、観客がさらにコメントを付けるなどして、双方向的なゲーム体験を生み出すことができる。

また、特許文献１には、ゲームプレイ動画の閲覧中に入力されたコメントを取得・集計し、演出方法を選択すること［００１１］が開示されている。ただし、特許文献１では、エフェクト、背景素材、及び画面装飾の異なる演出方法が定められているが、何れの演出方法も、ゲームプレイの内容そのものが変わるわけではなく、見た目が変わるだけである、とされている（［００８５］、［図１８］）。

特開２０１６−１８９８０４号公報 特開２０１３−１０６８５８号公報 特開２０１３−１３５７６１号公報

生放送の動画に対して観客がコメントを付け、それを配信者が閲覧できるという仕組みのみでは、観客のゲーム進行に対する影響力は限定的である。例えば、観客がいくらコメントを付けようとも配信者がこれを見落としたり無視したりすれば、観客のコメントはゲームの進行に影響を与えない。このように従来のゲーム実況生放送では、ゲームの進行に直接的に関与できるのは配信者のみであるから、配信者の意思と無関係に観客の意思がゲームの進行に影響を与えることはない。

一方、ゲーム実況生放送の観客が例えばアイテムの投下といった（サブ）イベントを発生させるなどしてゲームの進行に介入できるようにすることも想定される。このような枠組みによれば、ゲーム上では、プレイヤである配信者の操作により発生するイベントやゲームの進行に応じて自動的に発生するイベントに加えて、観客の介入によるイベントも発生することになる。これは、プレイヤのみがゲームを遊ぶ場合に比べて多くのイベントが発生し得ることを意味する。

多数の観客が同時多発的に介入を要求し、これにより配信者および観客の認知能力を超える数のイベントが短期間に集中して発生すれば、たとえそれぞれのイベントの発生が都度通知されたとしても配信者も観客もゲーム状態を把握することが困難となる。これは、ゲームおよびそのプレイ動画の面白さを損ねたり、配信者−観客間または観客間のコミュニケーションを阻害したりするなどして、双方向的なゲーム体験を破綻させるおそれがある。さらに、短期間に多数のイベントの発生を通知しようとすれば、ゲームの実行主体（ゲームサーバまたは配信者の端末）の処理負荷も重くなる。

特許文献２には、対戦型・自動実行型のゲームにおいて（００２１）、サーバ側のコンピュータの負荷が過大にならないようにするため（要約）、ゲーム入力を受け付ける「受付部」（［００２６］）、受け付けたゲーム入力に応じてゲーム実行処理をする「実行処理部」（［００２７］）、スケジュールに従って、複数のゲーム入力装置からのゲーム入力受付が、同期したタイミングで可能とされ又は不能とされるように決定する「決定部」（［００３５］）を備えたゲームサーバ装置が記載されている。

特許文献３には、ノンプレーヤキャラクタのメッセージの表示における制御負荷の増大を抑制するため（［０００７］）、メッセージのうち優先度が最も高いものを間引かないものとして選択するなど、優先度に基づいて適宜選択する（間引く）ことが記載されている（［００６３］）。

本発明は、イベントの発生が短期間に集中した場合にその通知に伴う悪影響を回避することを目的とする。

本発明の一態様によれば、ゲーム実行装置は、受信部と、イベント制御部と、選択部と、生成部とを含む。受信部は、ゲームのリアルタイムプレイ動画の観客の端末によって発行された当該ゲームに対する介入の実施要求を受信する補助サーバから、当該実施要求に基づくイベントの発生要求を受信する。イベント制御部は、少なくとも発生要求に応じて、ゲーム上で発生するイベントを制御する。選択部は、第１の期間内にゲーム上で発生する第１のイベントのうち所定個数を上限に通知対象イベントを選択する。生成部は、通知対象イベントの発生をゲームのプレイヤに通知する通知データを生成する。

本発明によれば、イベントの発生が短期間に集中した場合にその通知に伴う悪影響を回避することができる。

第１の実施形態に係るゲームサーバを含む、ゲームのリアルタイムプレイ動画の配信システムの一例を示すブロック図。 図１のゲームサーバを例示するブロック図。 優先度テーブルを例示する図。 図２のゲームサーバのイベント通知に関する動作の概念図。 通知データの一例を示す図。 通知データの別の例を示す図。 図２のゲームサーバの動作を例示するフローチャート。 図７のステップＳ７４０の詳細を例示するフローチャート。 第２の実施形態に係る配信者端末を含む、ゲームのリアルタイムプレイ動画の配信システムの一例を示すブロック図。 図９の配信者端末を例示するブロック図。

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

（第１の実施形態）
第１の実施形態に係るゲームサーバは、図１に例示される、ゲームのリアルタイムプレイ動画の配信システムに組み込むことができる。この配信システムは、配信者端末１００と、動画配信サーバ２００と、観客端末３００−１，３００−２，・・と、補助サーバ４００と、ゲームサーバ５００とを含む。

図１の例では、動画配信サーバ２００は、配信者端末１００（クライアント）およびゲームサーバ５００（サーバ）において実行されるＣ／Ｓ型のオンラインゲームのリアルタイムプレイ動画を、観客端末３００（および配信者端末１００）へ配信する。

ここで、ゲームは、例えば人工生命体の育成ゲームであってもよい。この育成ゲームにおいて、プレイヤは、人工生命体をフィールドと呼ばれる仮想世界に移し、その生態や当該人工生命体が群れ（一族）を形成して他の群れと共存する様子などを鑑賞して楽しむことができる。プレイヤは、自己の所有する人工生命体の死亡やその所属する一族の滅亡を防ぐため、その一族を有利にするため、などの目的で、人工生命体のエネルギーを補充するためのアイテム（フード）やその他の効果のあるオブジェクトをフィールドに投下することができる。このシステムでは、プレイヤである配信者だけでなく、観客も補助サーバ４００を利用してこのような介入を実施して、プレイヤ（配信者）と一緒に好みの人工生命体やその所属する一族をサポートしたり、逆に敵対勢力の活動を邪魔したりすることができる。

配信者端末１００は、ゲームプログラム（クライアントサイドプログラム）を実行する。配信者端末１００は、ゲームサーバ５００からゲームプログラム（サーバサイドプログラム）の実行結果を受信し、ゲーム画面／音声（振動、またはその他のフィードバックを含み得る）を出力し、プレイヤとしての配信者はこの出力を認知する。ここで、ゲームプログラムの実行結果とは、例えば、ゲーム画面／音声（のエンコード済みデータ）そのものであってもよいし、ゲーム状態のようなゲーム画面／音声を生成するために必要なデータであってもよい。例えば、クラウドゲームでは、ゲーム画面／音声そのものが配信者端末１００へ伝送され得る。

後者の例では、配信者端末１００は、ゲーム画面の描画および出力音声を決定するために、ゲームの素材データ、例えば、キャラクタ、オブジェクト、背景、ビジュアルエフェクト（ｖｉｓｕａｌ ｅｆｆｅｃｔ）などの画像データ、効果音（ＳＥ：Ｓｏｕｎｄ Ｅｆｆｅｃｔ）、ＢＧＭ(ｂａｃｋｇｒｏｕｎｄ ｍｕｓｉｃ)、キャラクターボイス（Ｃｈａｒａｃｔｅｒ Ｖｏｉｃｅ）、などの音声データ、振動パターン、などを主記憶または補助記憶装置に保存しておく必要がある。

プレイヤは、配信者端末１００からの出力を認知し、これに基づいて操作を当該配信者端末１００へ入力する。配信者端末１００はプレイヤの操作データをゲームサーバ５００へ送信する。さらに、配信者端末１００は、逐次、ゲーム画面／音声、そして必要があれば付加的な画像／音声をエンコードし、エンコード済みデータを動画配信サーバ２００へ送信（アップロード）する。ここで、付加的な画像／音声は、例えば、配信者を撮影した画像や配信者の実況音声などを含み得る。

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

なお、配信者端末１００は、ゲームプログラムを実行する装置（ゲーム実行装置）と、画像／音声をエンコードし、エンコード済みのマルチメディアデータを送信する装置（エンコード・アップロード装置）とに物理的に分離されてもよい。またこの場合に、ゲーム画面／音声のデータは、ゲーム実行装置からエンコード・アップロード装置へ直接的に出力されてもよいし、されなくてもよい。後者の場合には、例えば、ゲーム実行装置に接続された表示装置の画面を撮影し、スピーカからの出力音声を録音することで、エンコード・アップロード装置はゲーム画面／音声データを取り込むことができる。

動画配信サーバ２００は、配信者端末１００および観客端末３００とネットワーク経由で接続しており、データを互いに送受信できる。動画配信サーバ２００は、逐次、配信者端末１００からエンコード済みデータを受信し、これを観客端末３００へ送信する。

観客端末３００は、ユーザからの操作入力に基づいてゲームに対する介入の実施要求を発行し、補助サーバ４００へ送信する。観客端末３００は、配信者端末１００と同様の電子デバイスであり得る。ただし、観客端末３００は、ゲームプログラムを実行する能力は必要とされない。

補助サーバ４００は、観客端末３００およびゲームサーバ５００とネットワーク経由で接続している。補助サーバ４００は、観客端末３００から介入の実施要求を受信し、この要求に基づくイベントの発生要求をゲームサーバ５００へ送信する。イベントの発生要求は、例えば要求するイベントの種類を示すデータと、要求の主体である観客（以降、要求者と呼ぶ）を示すデータとを含み得る。以降の説明において、イベントおよびサブイベントは区別せず、いずれもイベントと称する。

補助サーバ４００がこのように動作することで、例えば、ゲームのリアルタイムプレイ動画を視聴する観客の意思の少なくとも一部が、当該ゲームの進行に影響し、ひいては当該観客の視聴するリアルタイムプレイ動画へも波及し、双方向的で一体感の高いゲーム体験を実現することができる。

なお、補助サーバ４００は、観客端末３００からの介入の実施要求を条件付きで受け付けてもよい。具体的には、補助サーバ４００は、対価（以降、介入対価とも称する）の支払いを条件に観客によるゲームへの介入を許容してもよい。ここで、介入対価とは、現実の財貨によって表されてもよいし、動画配信サービスにおいて使用可能な仮想的な財貨（ポイントを含む）によって表されてもよい。観客は、ゲームへの介入を実施したい場合には、観客端末３００に表示された介入対価の支払いに同意のうえ当該観客端末３００を操作して実施要求を発行する。補助サーバ４００は、観客端末３００から介入の実施要求を受信すると、当該要求の発行時に当該観客端末３００に表示されていた介入対価と引き替えに、ゲームに対して当該介入を実施する。なお、介入対価の決済処理は、補助サーバ４００が行ってもよいし、補助サーバ４００とは別の決済サーバが行ってもよい。

ゲームサーバ５００は、配信者端末１００とネットワーク経由で接続しており、互いにデータを送受信できる。ゲームサーバ５００は、ゲームプログラムを実行する。第１の実施形態に係るゲームサーバ５００は、ゲーム実行装置と呼ぶことができる。

ゲームサーバ５００は、配信者端末１００から送信されるプレイヤの操作データと、補助サーバ４００からのイベントの発生要求とに基づいて、ゲーム状態を遷移させる。ゲームサーバ５００は、逐次、ゲームプログラムの実行結果を配信者端末１００へ送信する。

ゲームサーバ５００は、プレイヤの操作データおよびイベントの発生要求に基づいて発生するイベント、ゲームの進行に応じて自動的に発生するイベント、のうちの少なくとも一部について、そのイベントの発生をプレイヤに通知するための通知データを生成する。ただし、ゲームサーバ５００は、以下に説明するように、単位期間内に通知対象とするイベント数を制限し、イベントの発生が短期間に集中した場合であっても所定個数（例えば１個）を超えるイベントを通知しない。これにより、プレイヤおよび観客がゲーム状態をある程度把握できるようにしながらも、プレイヤおよび観客に提供されるゲーム体験が破綻するのを回避することができる。また、通知に伴うゲームサーバ５００の負荷が一定の上限を超えて増加することはない。

なお、図１において示される各装置の数は、例示に過ぎない。例えば、観客端末３００の数は、時々刻々と変化するので、０となることがあり得るし、数百、数千となることもあり得る。また、図１に示されないＷｅｂサーバまたはコメント配信サーバがさらに設けられてもよい。

以下、図２乃至図８を用いて、ゲームサーバ５００について詳しく説明する。
ゲームサーバ５００は、コンピュータであって、例えば、入出力制御、通信制御、そしてゲームの実行（すなわち、イベントの制御、後述される通知対象イベントの選択、通知データの生成、など）を行うプロセッサを含む。また、ゲームサーバ５００は、かかる処理を実現するために当該プロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータなどを一時的に格納するメモリを含んでいる。

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

また、ゲームサーバ５００は、複数のコンピュータの組み合わせであってよい。例えば、ゲームサーバ５００の機能部、例えば後述される通信部５１０とゲーム実行部５２０および種々の記憶部とが別個のコンピュータに分散して実装されてもよい。

ゲームサーバ５００は、さらに、ネットワークに接続するための通信Ｉ／Ｆ（インタフェース）を利用可能である。通信Ｉ／Ｆは、ゲームサーバ５００に内蔵されてもよいし、ゲームサーバ５００に外付けされてもよい。

通信Ｉ／Ｆは、ネットワーク経由で、配信者端末１００および補助サーバ４００と通信をするためのモジュールであり得る。例えば、通信Ｉ／Ｆは、配信者端末１００からプレイヤの操作データを受信したり、逆に配信者端末１００へゲームプログラムの実行結果を送信したりする。また、通信Ｉ／Ｆは、補助サーバ４００からイベントの発生要求を受信する。さらに、通信Ｉ／Ｆは、要求者の属性データ（後述される）を、補助サーバ４００、または動画配信サーバ２００から受信し得る。

次に、図２を用いてゲームサーバ５００の構成例の説明を続ける。図２のゲームサーバ５００は、通信部５１０と、ゲーム実行部５２０と、種々の記憶部とを含む。

通信部５１０は、例えば前述の通信Ｉ／Ｆであってよく、ネットワーク経由で、外部装置、例えば、配信者端末１００、補助サーバ４００、などからデータを受信したり、外部装置へデータを送信したりする。具体的には、通信部５１０は、受信部５１１および送信部５１２を含む。

受信部５１１は、配信者端末１００からプレイヤの操作データを受信する。また、受信部５１１は、補助サーバ４００からイベントの発生要求を受信する。さらに、受信部５１１は、補助サーバ４００、または動画配信サーバ２００から、観客の属性データを受信する。受信部５１１は、これらの受信データをゲーム実行部５２０へ送る。具体的には、受信部５１１は、観客の属性データを属性取得部５２１へ送る。なお、属性データの詳細は後述するが、属性データは必ずしもイベントの発生要求と独立したデータである必要はなく、イベントの発生要求にその要求者の属性データが付加されていてもよい。また、受信部５１１は、プレイヤの操作データおよびイベントの発生要求を、少なくともイベント制御部５２２へ送る。

送信部５１２は、ゲーム実行部５２０からゲームプログラムの実行結果を受け取り、これを配信者端末１００へ送信する。ここで、ゲームプログラムの実行結果には、少なくとも、ゲーム上で発生するイベントを示すデータと、後述される通知データとが含まれる。前述のように、実行結果は、ゲーム画面／音声（のエンコード済みデータ）であってもよいし、ゲーム状態のようなゲーム画面／音声を生成するために必要なデータであってもよい。後者の場合に、イベントを示すデータは、例えば、イベントのＩＤ、イベントの種類、イベントの発生時間および場所などを含み得るし、通知データは、通知対象イベントのＩＤを含み得るし、さらに必要に応じてその通知態様（例えば通知順および通知時間）などを示すデータを含み得る。

ゲーム実行部５２０は、前述のプロセッサおよびメモリであってよく、ゲームプログラム（サーバサイドプログラム）を実行する。ゲーム実行部５２０は、通信部５１０からプレイヤの操作データ、イベント発生要求、などのデータを受け取り、種々の記憶部から必要なデータを読み出し、これらに基づいてゲーム状態を遷移させたり、通知データを生成したりする。例えば、ゲーム実行部５２０は、新たなキャラクタ、アイテム、オブジェクト、などを仮想空間に追加したり、既存のキャラクタ、アイテム、オブジェクト、などを仮想空間から削除したりその状態を変化させたりする。ゲーム実行部５２０は実行結果を通信部５１０に返す。具体的には、ゲーム実行部５２０は、属性取得部５２１と、イベント制御部５２２と、通知対象選択部５２３と、通知データ生成部５２４とを含む。

属性取得部５２１は、要求者ないし観客の属性を示す属性データを、通信部５１０を介して取得する。属性取得部５２１は、属性データを属性記憶部５３１に保存する。

要求者の属性は、通知対象イベントの選択において補助的に参照され得る。すなわち、後述される優先度の降順にイベントを選択すると、候補数が所定個数（通知対象イベントの上限数）をオーバーする場合に、要求者の属性に基づいて候補が絞りこまれ得る。ただし、要求者の属性を通知対象イベントの選択において全く利用しないことも可能である。この場合には、属性取得部５２１および属性記憶部５３１は削除され得る。

ここで、要求者の属性は、例えば、要求者がゲームのリアルタイムプレイ動画の視聴を開始した時間を含み得る。かかる情報は、例えば動画配信サーバ２００から得ることができる。また、要求者の属性は、当該要求者が介入の実施を要求した時間を含み得る。かかる情報は、例えば補助サーバ４００から得ることができる。さらに、要求者の属性は、ゲームのリアルタイムプレイ動画において当該要求者からの要求によりゲーム上で発生したイベントが（いずれかの単位期間における）通知対象イベントとして選択された回数（通知対象イベントの採用回数）を含み得る。かかる情報は、例えば通知対象選択部５２３の出力に基づいて、ゲームサーバ５００において管理することができる。具体的には、通知対象選択部５２３は、単位期間における通知対象イベントの要求者のそれぞれについて、属性記憶部５３１に保存された通知対象イベントの採用回数を１インクリメントすればよい。

イベント制御部５２２は、プレイヤの操作データおよびイベントの発生要求を受信部５１１から受け取る。なお、プレイヤの操作データおよびイベントの発生要求は、それぞれ独立したデータであるから、イベント制御部５２２がこれらを独立したタイミングで受け取る。

イベント制御部５２２は、プレイヤの操作データおよびイベントの発生要求のそれぞれに応じて、ゲーム上で発生するイベントを制御する。また、イベント制御部５２２は、ゲームプログラムの仕様次第で、プレイヤの操作データおよびイベントの発生要求のいずれも受け取らなかった場合にも、ゲームの進行に応じてイベントを発生させることもあり得る。イベント制御部５２２は、ゲーム上で発生するイベントを示すデータを送信部５１２および通知対象選択部５２３へ送る。なお、ゲームサーバ５００がゲーム画面／音声（のエンコード済みデータ）を生成して配信者端末１００へ送信する場合には、イベント制御部５２２は、送信部５１２ではなく図示されないゲーム画面／音声生成部へ、ゲーム上で発生するイベントを示すデータを送ってもよい。

通知対象選択部５２３は、イベント制御部５２２からゲーム上で発生するイベントを示すデータを受け取る。通知対象選択部５２３は、単位期間毎に、当該単位期間内にゲーム上で発生するイベントのうち所定個数を上限に通知対象イベントを選択する。通知対象選択部５２３は、通知対象イベントを示すデータを通知データ生成部５２４へ送る。ここで、所定個数は、１個であってもよいし、複数であってもよい。また、所定個数は、固定値であってもよいし、可変値であってもよい。例えば、人間のゲーム内イベントの通知に関する認知能力は本人の情報処理能力や当該ゲームのプレイ経験に応じてある程度異なると考えられるので、配信者または観客が所定個数を自由に設定できるようにしてもよい。また、単位期間は、固定長であってもよいし、可変長であってもよい。

具体的には、通知対象選択部５２３は、イベントの種類毎に予め定義されている優先度の降順に通知対象イベントを選択してもよい。或いは、通知対象選択部５２３は、ランダムに通知対象イベントを選択してもよいし、イベントの発生の早い順または遅い順に通知対象イベントを選択してもよい。ただし、以降の説明では、通知対象選択部５２３は、優先度の降順に通知対象イベントを選択することとする。

優先度の降順に通知対象イベントを選択することは、ゲームの進行への影響が大きいイベントが通知対象イベントから漏れにくくなるという効果がある。通知対象選択部５２３は、単位期間内に発生するイベント毎に当該イベントの種類に割り当てられた優先度を優先度記憶部５３３から読み出す。

イベントの種類とその優先度とを対応付ける優先度テーブルの一例を図３に示す。図３において、優先度は、５（最高）から１（最低）までの５段階で付与されている。また、観客が関与可能、すなわち発生を要求可能なイベントには○印が付加されている。故に、例えば所定個数が「１」であり、「フード（低価値）をフィールドに投下した」（優先度１）と、「オブジェクトの効果が発動した」（優先度３）と、「新しい人工生命体をフィールドに投下した」（優先度４）とが同一の単位期間内に発生するとすれば、通知対象選択部５２３は、優先度の最も高い「新しい人工生命体をフィールドに投下した」を通知対象イベントとして選択する。なお、図３は例示に過ぎないので、優先度を図３と異なるように割り当てることも可能である。

ここで、単位期間内に発生するイベントに割り当てられた優先度を降順にソートした場合に所定個数番目に並ぶ優先度を境界値と定める。故に、通知対象イベントは、いずれも境界値以上の優先度を割り当てられることになる。ただし、境界値に等しい優先度を割り当てられたイベントが複数存在する場合に、通知対象イベントの候補が所定個数を超えることがある。このように、単位期間内に発生するイベントのうち、境界値以上の優先度を割り当てられたものが所定個数を超える場合に、通知対象選択部５２３は、境界値に等しい優先度を割り当てられたイベントのうちの一部をその要求者の属性に基づいて通知対象イベントとして選択してもよい。通知対象選択部５２３は、境界値に等しい優先度を割り当てられたイベントのそれぞれの要求者の属性データを属性記憶部５３１から読み出す。

なお、要求者が存在しないイベント、例えば、プレイヤの操作データに基づいて発生するイベント、またはゲームの進行に応じて自動発生するイベントについても、何らかの属性データ（属性値）がデフォルトで定められてもよい。

例えば、通知対象選択部５２３は、ゲームのリアルタイムプレイ動画の視聴を開始した時間が遅い要求者からの要求により発生するイベントを優遇してもよい。これにより、例えば浮動客の定着が期待できる。逆に、通知対象選択部５２３は、ゲームのリアルタイムプレイ動画の視聴を開始した時間が早い要求者からの要求により発生するイベントを優遇してもよい。これにより、固定客の視聴／介入意欲の維持ないし向上が期待できる。

また、通知対象選択部５２３は、通知対象イベントの採用回数が少ない要求者からの要求により発生するイベントを優遇してもよい。これにより、各要求者による介入が満遍なく注目されやすくなるので、各要求者の視聴／介入意欲が低下しにくくなる。さらに、通知対象選択部５２３は、介入の実施を要求した時間の早い、または遅い要求者からの要求により発生するイベントを優遇してもよい。

通知対象選択部５２３は、１つの属性に基づく候補の絞り込みを行ってもよいし，複数の属性に基づく候補の絞り込みを行ってもよい。後者の例では、いくつかの属性を組み合わせて指標化しこの指標に基づく候補の絞り込みを行ってもよいし、単独の属性に基づく候補の絞り込みを順番に行ってもよい。

或いは、単位期間内に発生するイベントのうち、境界値以上の優先度を割り当てられたものが所定個数を超える場合に、通知対象選択部５２３は、境界値に等しい優先度を割り当てられたイベントのうちの一部を通知対象イベントとしてランダムに選択してもよい。また、通知対象選択部５２３は、前述の要求者の属性を用いても候補の絞り込みが不十分である場合に、残存する候補から通知対象イベントをランダムに選択してもよい。

単位期間内に発生するイベントの数は必ずしも一定でないので、所定個数を超えるイベントが発生することもあれば、所定個数以下のイベントが発生することもある。後者の場合に、通知対象選択部５２３は、全てのイベントを通知対象イベントとして選択できる。さらに、単位期間内に発生するイベントの数が所定個数を下回る場合には、当該単位期間内に発生するイベントを全て通知してもなお、イベント通知のためのリソース（時間および／または画面内空間）に空きが生じることになる。そこでかかる場合には、通知対象選択部５２３は、過去の単位期間に発生したイベントであって、当該過去の単位期間における通知対象イベントとして選択されなかったイベント（以降、未通知イベントと称する）を、現行の単位期間における通知対象イベントとしてさらに選択してもよい。これにより、プレイヤおよび観客の認知能力を超えない範囲で、より多くのイベントの発生をプレイヤ、そして観客に通知することが可能となる。

かかる未通知イベントの時間差通知を実現するためには、未通知イベントを示すデータを管理しておく必要がある。通知対象選択部５２３は、各単位期間について通知対象イベントを選択すると共に、当該単位期間における未通知イベントを示すデータを例えば当該単位期間を示すデータに対応付けて、未通知イベント記憶部５３４に保存する。そして、通知対象選択部５２３は、単位期間内に発生するイベントの数が所定個数を下回る場合に、未通知イベントを示すデータを未通知イベント記憶部５３４から読み出す。

通知対象選択部５２３は、例えば、前述の優先度、要求者の属性などを考慮して、未通知イベントの一部を通知対象イベントとして決定してもよい。また、通知対象選択部５２３は、未通知イベントの発生からの経過時間をさらに考慮してもよい。例えば、通知対象選択部５２３は、発生からの経過時間の短い未通知イベントを優遇してもよい。これにより、古過ぎるイベントの発生が通知されることで、却って、プレイヤ、そして観客が混乱するのを避けることができる。また、通知対象選択部５２３が未通知イベントの発生からの経過時間を直接考慮せずとも、例えば、経過時間が閾値以上の未通知イベントを示すデータを未通知イベント記憶部５３４から削除したり、未通知イベント記憶部５３４における当該データの保存数を最新Ｕ個（Ｕは任意の自然数）に制限したりしてもよい。

通知データ生成部５２４は、通知対象選択部５２３から通知対象イベントを示すデータを受け取り、当該通知対象イベントの発生をゲームのプレイヤに通知する（すなわち、最終的に観客にも通知する）通知データを生成する。通知データ生成部５２４は、通知データを送信部５１２へ送る。

ここで、通知データは、通知対象イベントの発生をプレイヤに通知する画像データを配信者端末１００に表示されるゲーム画面に重畳（例えば、ピクチャーインピクチャー（Ｐｉｃｔｕｒｅ−ｉｎ−Ｐｉｃｔｕｒｅ）表示）するためのデータであり得る。具体的には、通知データは、かかる画像データそのものであってもよいし、当該画像データを配信者端末１００において描画するために必要なデータであってもよい。また、画像データは、通知対象イベントが発生した時間および／または場所の情報を含んでいてもよい。これにより、プレイヤおよび観客はゲーム状態をより正確に認知することができる。また、画像データは、通知対象イベントの要求者の情報を含んでいてもよい。これにより、要求者の視聴／介入意欲の維持ないし向上が期待できる。

かかる画像データは、例えば、図５のように、通知対象イベントの発生地点付近をゲーム画面の（仮想）視点とは異なる視点から見たサブ画面を含み得る。図５の画像データによれば、プレイヤおよび観客は、通知対象イベントの発生を視覚的に認知することができる。或いは、画像データは、例えば図６のように、通知対象イベントの発生を記述するテキスト画像を含み得る。図６の画像データによれば、図５の例に比べて、メインのゲーム画面の表示領域の遮蔽を抑制することができる。なお、図５および図６の画像データは、併用することも可能である。どちらの画像データが使用されるかは、プレイヤまたは観客が設定できるようにしてもよいし、通知対象イベントの種類に応じて切り替えられてもよいし、通知対象選択部５２３における当該通知対象イベントの選択順に応じて切り替えられてもよい（例えば、選択順が上位Ａ（Ａは任意の自然数）個までは図５の画像データが使用され残りは図６の画像データが使用されてもよい）。

なお、図１のシステムにおいて多視点配信が行われている場合に、かかる画像データを異なる視点へのリンクとして利用することもできる。すなわち、観客が観客端末３００上で例えば図５のようなサブ画面を選択した場合に、当該観客端末３００に配信されるメインの視点が当該サブ画面に対応する視点に切り替わってもよい。

或いは、通知データは、通知対象イベントの発生をゲームのプレイヤに通知する音声データを配信者端末１００から出力するためのデータであり得る。すなわち、通知対象イベントの発生を記述するテキストデータ（これは配信者端末１００においてＴＴＳ（Ｔｅｘｔ−Ｔｏ−Ｓｐｅｅｃｈ）処理の対象となる）であってもよいし、かかるテキストデータからＴＴＳ処理によって得られる音声データ（のエンコード済みデータ）であってもよい。

ここで、図４を用いて、ゲームサーバ５００がイベント通知に関してどのように動作するかを概念的に説明する。図４の例では、単位期間Ｔ１にイベント１、イベント２およびイベント３が発生し、続く単位期間Ｔ２にイベント４が発生しているとする。また単位期間Ｔ１および単位期間Ｔ２における所定個数（通知対象イベントの上限数）は２個であるとする。

まず、イベント制御部５２２が、単位期間Ｔ１内にゲーム上でイベント１、イベント２およびイベント３を発生することを決定する。イベント制御部５２２は、かかる情報を通知対象選択部５２３へ逐次報告する。

その後、通知対象選択部５２３は、単位期間Ｔ１内に発生するイベント１、イベント２およびイベント３から、２個を上限に通知対象イベントを選択する。図４の例では、通知対象選択部５２３は、イベント１およびイベント２を通知対象イベントとして選択し、イベント３を未通知イベントとしてイベント３を示すデータを未通知イベント記憶部５３４に保存する。なお、図４の例では、通知対象選択部５２３は、単位期間Ｔ２中に通知対象イベントを選択しているが、これは例示に過ぎない。原理上、通知対象選択部５２３は、単位期間Ｔ１の満了までに発生するイベントがイベント制御部５２２によって決定された後の任意のタイミングで、当該単位期間Ｔ１における通知対象イベントを選択することができる。

その後、通知データ生成部５２４によって生成された通知データによって、イベント１およびイベント２の発生が配信者端末１００に表示されるゲーム画面上で通知される。図４の例では、単位期間Ｔ２に続く単位期間Ｔ３中にイベント１およびイベント２の発生が通知されているが、これは例示に過ぎない。原理上、単位期間Ｔ１における通知対象イベントが通知対象選択部５２３によって選択され、その通知データが通知データ生成部５２４によって生成され、そして配信者端末１００へ伝送された後の任意のタイミングで、当該通知対象イベントの通知が可能である。

さらに、イベント制御部５２２が、単位期間Ｔ２内にゲーム上でイベント４を発生することを決定する。イベント制御部５２２は、かかる情報を通知対象選択部５２３へ報告する。

その後、通知対象選択部５２３は、単位期間Ｔ２内に発生するイベント４を通知対象イベントとして選択する。図４の例では、単位期間Ｔ２における所定個数は２個に定められているので、通知対象選択部５２３は、未通知イベントであるイベント３を通知対象イベントとしてさらに選択する。すなわち、通知対象選択部５２３は、イベント３およびイベント４を単位期間Ｔ２における通知対象イベントとして選択する。なお、図４の例では、通知対象選択部５２３は、単位期間Ｔ３中に通知対象イベントを選択しているが、これは例示に過ぎない。原理上、通知対象選択部５２３は、単位期間Ｔ２の満了までに発生するイベントがイベント制御部５２２によって決定された後の任意のタイミングで、当該単位期間Ｔ２における通知対象イベントを選択することができる。

その後、通知データ生成部５２４によって生成された通知データによって、イベント３およびイベント４の発生が配信者端末１００に表示されるゲーム画面上で通知される。図４の例では、単位期間Ｔ３に続く単位期間Ｔ４中にイベント３およびイベント４の発生が通知されているが、これは例示に過ぎない。原理上、単位期間Ｔ２における通知対象イベントが通知対象選択部５２３によって選択され、その通知データが通知データ生成部５２４によって生成され、そして配信者端末１００へ伝送された後の任意のタイミングで、当該通知対象イベントの通知が可能である。

図２の例において種々の記憶部は、属性記憶部５３１、ゲームデータ記憶部５３２、優先度記憶部５３３と、未通知イベント記憶部５３４とを含む。これらの記憶部は、前述のメモリ単体であってもよいし、メモリおよび補助記憶装置の組み合わせであってもよい。

属性記憶部５３１は、要求者ないし観客の属性を示す属性データを保存する。属性データは、属性取得部５２１および／または通知対象選択部５２３によって書き込まれ、または書き換えられる。また、属性データは、通知対象選択部５２３によって読み出される。

ゲームデータ記憶部５３２は、ゲームプログラムによって使用される種々のゲームデータを保存する。ゲームデータは、ゲームプログラムのインストールまたはアップデート時にゲームデータ記憶部５３２に書き込まれ、または書き換えられ得る。ゲームデータは、イベント制御部５２２によって読み出される。図２の例では、ゲームサーバ５００は必ずしもゲーム画面／音声の生成を行わないので、ゲームデータは必ずしも素材データを含まない。

優先度記憶部５３３は、例えば図３に示した優先度テーブルの形式で、イベントの種類に対応付けて優先度を保存する。優先度は、例えばゲームプログラムのインストールまたはアップデート時に優先度記憶部５３３に書き込まれ、または書き換えられ得る。優先度は、通知対象選択部５２３によって読み出される。

未通知イベント記憶部５３４は、前述の未通知イベントを示すデータを保存する。このデータは、通知対象選択部５２３によって書き込まれ、または書き換えられる。このデータは、通知対象選択部５２３によって読み出される。

次に、図７を用いて、１つの単位期間についてのゲームサーバ５００の動作例を説明する。
まず、受信部５１１は、補助サーバ４００からイベントの発生要求を受信し（ステップＳ７１０）、または配信者端末１００からプレイヤの操作データを受信する（ステップＳ７２０）。そして、イベント制御部５２２は、ステップＳ７１０において受信したイベントの発生要求、またはステップＳ７２０において受信したプレイヤの操作データに基づいて、イベントを制御する（ステップＳ７３０）。具体的には、イベント制御部５２２は、どのイベントを発生させるかを決定する。

かかる処理が、単位期間の満了までに発生する全てのイベントが決定するまで繰り替えされ（ステップＳ７３５）、処理はステップＳ７４０へ進む。他方、次の単位期間について図７の動作が並列的に開始し得る。すなわち、イベント制御部５２２は、次の単位期間に発生するイベントを制御し始める。

なお、図７は単なる例示に過ぎず、イベント制御部５２２は、イベントの発生要求またはプレイヤの操作データのいずれも受信しない場合であっても、ゲームの進行に応じて自動的にイベントの発生を決定することもある。

ステップＳ７４０において、通知対象選択部５２３は、ステップＳ７３０において決定された、単位期間内に発生するイベントのうち所定個数を上限に通知対象イベントを選択する。なお、ステップＳ７４０の詳細は、図７の説明の後に図８を用いて説明する。

次に、通知データ生成部５２４は、ステップＳ７４０において選択された通知対象イベントの発生をゲームのプレイヤに通知する通知データを生成する（ステップＳ７５０）。そして、送信部５１２は、ステップＳ７５０において生成された通知データを含む、ゲームプログラムの実行結果を配信者端末１００へ送信する（ステップＳ７６０）。

次に、図８を用いて、図７のステップＳ７４０の詳細を説明する。
まず、通知対象選択部５２３は、単位期間内に発生するイベントの数を計数し、これが当該単位期間に対して定められた所定個数を超えるか否かを判定する（ステップＳ７４１）。単位期間内の発生イベント数が所定個数を超える場合には処理はステップＳ７４２へと進み、そうで無い場合には処理はステップＳ７４５へ進む。

ステップＳ７４２において、通知対象選択部５２３は、所定個数を上限として優先度の降順に通知対象イベントを選択する。ここで、優先度が前述の境界値以上のイベントの数が所定個数を超えない、すなわち優先度が前述の境界値以上のイベントの数が所定個数に等しい場合には、ステップＳ７４２を以て通知対象イベントの選択は完了する。他方、優先度が前述の境界値以上のイベントの数が所定個数を超える場合には、通知対象選択部５２３は、優先度＝境界値のイベントを絞り込む（ステップＳ７４４）。例えば、通知対象選択部５２３は、前述の要求者の属性を利用してもよいし、ランダム選択を行ってもよいし、両者を組み合わせてもよい。

ステップＳ７４５において、通知対象選択部５２３は、単位期間内に発生するイベントを全て通知対象イベントとして選択する。ここで、選択済みの通知対象イベントの数が所定個数未満でない、すなわち選択済みの通知対象イベントの数が所定個数に等しい場合にはステップＳ７４５を以て通知対象イベントの選択は完了する。他方、選択済みの通知対象イベントの数が所定個数未満である場合には、通知対象選択部５２３は、前述の未通知イベントを通知対象イベントとしてさらに選択する（ステップＳ７４７）。

以上説明したように、第１の実施形態に係るゲームサーバは、単位期間内に発生するイベントのうち所定個数を上限に通知対象イベントを選択し、当該通知対象イベントの発生をプレイヤ、そして最終的には観客に通知する。故に、このゲームサーバによれば、イベントの発生が短期間に集中した場合であっても所定個数を限度に通知が行われるので、プレイヤおよび観客がゲーム状態をある程度把握できるようにしながらも、プレイヤおよび観客に提供されるゲーム体験が破綻するのを回避することができる。また、通知に伴うゲームサーバの負荷が一定の上限を超えて増加することはない。

（第２の実施形態）
第２の実施形態に係る配信者端末は、図９に例示される、ゲームのリアルタイムプレイ動画の配信システムに組み込むことができる。この配信システムは、配信者端末６００と、動画配信サーバ２００と、観客端末３００−１，３００−２，・・と、補助サーバ４００とを含む。

図９の例では、動画配信サーバ２００は、配信者端末６００において実行されるスタンドアローン型のゲームまたはＰ２Ｐ型のオンラインゲームのリアルタイムプレイ動画を、観客端末３００（および配信者端末６００）へ配信する。

図９の動画配信サーバ２００、観客端末３００および補助サーバ４００は、図１の動画配信サーバ２００、観客端末３００および補助サーバ４００と同一であり得る。ただし、図１に関する説明における「配信者端末１００」および「ゲームサーバ５００」を「配信者端末６００」に置き換える必要がある。

配信者端末６００は、ゲームプログラムを実行する。また、配信者端末６００は、ゲームの素材データをその主記憶または補助記憶装置に保存しているものとする。第２の実施形態に係る配信者端末６００は、ゲーム実行装置と呼ぶことができる。

配信者端末６００は、プレイヤからの操作を受け付け、補助サーバ４００からのイベント発生要求を受信する。配信者端末６００は、プレイヤの操作データとイベントの発生要求とに基づいて、ゲーム状態を遷移させる。配信者端末６００は、逐次、ゲーム状態およびゲームの素材データに基づいて、ゲーム画面／音声を生成して出力する。

プレイヤは、配信者端末６００からの出力を認知し、これに基づいて操作を当該配信者端末６００へ入力する。配信者端末６００はプレイヤの操作を受け付けて、ゲーム状態をさらに遷移させる。さらに、配信者端末６００は、逐次、ゲーム画面／音声、そして必要があれば付加的な画像／音声をエンコードし、動画配信サーバ２００へ送信する。

配信者端末６００は、プレイヤの操作データおよびイベントの発生要求に基づいて発生するイベント、ゲームの進行に応じて自動的に発生するイベント、のうちの少なくとも一部について、そのイベントの発生をプレイヤに通知するための通知データを生成する。ただし、配信者端末６００は、以下に説明するように、単位期間内に通知対象とするイベント数を制限し、イベントの発生が短期間に集中した場合であっても所定個数を超えるイベントを通知しない。これにより、プレイヤおよび観客がゲーム状態をある程度把握できるようにしながらも、プレイヤおよび観客に提供されるゲーム体験が破綻するのを回避することができる。また、通知に伴う配信者端末６００の負荷が一定の上限を超えて増加することはない。

配信者端末６００は、ゲームプログラムが実行可能なコンピュータなどの電子デバイス、例えば、図１の配信者端末１００と同様の電子デバイスであり得る。なお、配信者端末６００は、ゲームプログラムを実行する装置（ゲーム実行装置）と、画像／音声をエンコードし、エンコード済みのマルチメディアデータを送信する装置（エンコード・アップロード装置）とに物理的に分離されてもよい。またこの場合に、ゲーム画面／音声のデータは、ゲーム実行装置からエンコード・アップロード装置へ直接的に出力されてもよいし、されなくてもよい。後者の場合には、例えば、ゲーム実行装置に接続された表示装置の画面を撮影し、スピーカからの出力音声を録音することで、エンコード・アップロード装置はゲーム画面／音声データを取り込むことができる。

なお、図９において示される各装置の数は、例示に過ぎない。例えば、観客端末３００の数は、時々刻々と変化するので、０となることがあり得るし、数百、数千となることもあり得る。また、図９に示されないＷｅｂサーバまたはコメント配信サーバがさらに設けられてもよい。

配信者端末６００は、例えば、入出力制御、通信制御、そしてゲームの実行（すなわち、イベントの制御、通知対象イベントの選択、通知データの生成、など）を行うプロセッサを含む。また、配信者端末６００は、かかる処理を実現するために当該プロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータなどを一時的に格納するメモリを含んでいる。

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

また、配信者端末６００は、複数のコンピュータの組み合わせであってよい。例えば、配信者端末６００の機能部、例えば後述される通信部６１０とゲーム実行部６２０および種々の記憶部とが別個のコンピュータに分散して実装されてもよい。

配信者端末６００は、さらに、ネットワークに接続するための通信Ｉ／Ｆを利用可能である。通信Ｉ／Ｆは、配信者端末６００に内蔵されてもよいし、配信者端末６００に外付けされてもよい。

通信Ｉ／Ｆは、ネットワーク経由で、動画配信サーバ２００および補助サーバ４００と通信をするためのモジュールであり得る。例えば、通信Ｉ／Ｆは、エンコード済みデータを動画配信サーバへ送信（アップロード）する。また、通信Ｉ／Ｆは、補助サーバ４００からイベントの発生要求を受信する。さらに、通信Ｉ／Ｆは、要求者の属性データを、補助サーバ４００、または動画配信サーバ２００から受信し得る。

配信者端末６００は、さらに、ユーザ入力を受け付けるための入力装置を利用可能である。入力装置は、配信者端末６００に内蔵されてもよいし、配信者端末６００に外付けされてもよい。

入力装置は、例えば、キーボード、マウス、テンキー、マイクロフォン、カメラなどであってもよいし、タッチスクリーンのように出力装置の機能を備えていてもよい。ユーザ入力は、典型的には、タップ、クリック、ドラッグ、特定のキーの押下などであり得る。このほか、ユーザ入力は、例えば、マイクロフォンによって捉えられる音声、生体センサによって検出される生体データ（例えば体温、表情など）、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）または基地局情報によって識別される位置データ、加速度センサによって検出される加速度データに基づいて推定されるユーザのアクション（例えば、配信者端末６００を振り回した）などを含むこともできる。

配信者端末６００は、さらに、例えばゲーム画面／音声／振動を出力するための出力装置を利用可能である。出力装置は、配信者端末６００に内蔵されてもよいし、配信者端末６００に外付けされてもよい。

出力装置は、動画像、静止画像、テキストなどを表示するための表示デバイス、音声、楽曲などを出力するためのスピーカ、所望のパターンで振動するバイブレータ、などを含み得る。表示デバイスは、例えば、液晶ディスプレイ、有機ＥＬ（ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）ディスプレイなどである。表示デバイスは、コンテンツを含む表示データを表示する。なお、表示デバイスは、タッチスクリーンのように入力装置の機能を備えていてもよい。

次に、図１０を用いて配信者端末６００の構成例の説明を続ける。図１０の配信者端末６００は、通信部６１０と、ゲーム実行部６２０と、種々の記憶部と、入力部６４１と、エンコーダ６４２と、出力部６４３とを含む。

通信部６１０は、例えば前述の通信Ｉ／Ｆであってよく、ネットワーク経由で、外部装置、例えば、動画配信サーバ２００、補助サーバ４００、などからデータを受信したり、外部装置へデータを送信したりする。具体的には、通信部６１０は、受信部６１１および送信部６１２を含む。

受信部６１１は、補助サーバ４００からイベントの発生要求を受信する。また、受信部６１１は、補助サーバ４００、または動画配信サーバ２００から、観客の属性データを受信する。受信部６１１は、これらの受信データをゲーム実行部６２０へ送る。具体的には、受信部６１１は、観客の属性データを属性取得部６２１へ送る。また、受信部６１１は、イベントの発生要求を、少なくともイベント制御部６２２へ送る。

送信部６１２は、エンコーダ６４２からエンコード済みデータを受け取り、これを動画配信サーバ２００へ送信する。

ゲーム実行部６２０は、前述のプロセッサおよびメモリであってよく、ゲームプログラムを実行する。ゲーム実行部６２０は、入力部６４１および通信部６１０からプレイヤの操作データ、イベント発生要求などのデータを受け取り、種々の記憶部から必要なデータを読み出し、これらに基づいてゲーム状態を遷移させたり、通知データを生成したりする。さらに、ゲーム実行部６２０は、ゲーム状態の遷移に応じてゲーム画面を描画し、出力するゲーム音声（および振動パターン）を決定する。そして、ゲーム実行部６２０は、ゲーム画面／音声をエンコーダ６４２および出力部６４３へ送る。具体的には、ゲーム実行部６２０は、属性取得部６２１と、イベント制御部６２２と、通知対象選択部６２３と、通知データ生成部６２４と、ゲーム画面／音声生成部６２５とを含む。

ただし、属性取得部６２１は、図２の属性取得部５２１と同一または類似であってよい。イベント制御部６２２は、ゲーム上で発生するイベントを示すデータの出力先を除いて、図２のイベント制御部５２２と同一または類似であってよい。通知対象選択部６２３は、図２の通知対象選択部５２３と同一または類似であってよい。通知データ生成部６２４は、通知データの出力先を除いて、図２の通知データ生成部５２４と同一または類似であってよい。

ゲーム画面／音声生成部６２５は、イベント制御部６２２からゲーム上で発生するイベントを示すデータを受け取り、通知データ生成部６２４から通知データを受け取り、ゲームデータ記憶部６３２からゲームデータ（素材データを含む）を読み出す。ゲーム画面／音声生成部６２５は、これらに基づいて、ゲーム画面を描画し、出力するゲーム音声（および振動パターン）を決定する。ゲーム画面／音声生成部６２５は、生成したゲーム画面／音声データをエンコーダ６４２および出力部６４３へ送る。

図１０の例において種々の記憶部は、属性記憶部６３１、ゲームデータ記憶部６３２、優先度記憶部６３３と、未通知イベント記憶部６３４とを含む。これらの記憶部は、前述のメモリ単体であってもよいし、メモリおよび補助記憶装置の組み合わせであってもよい。

ただし、属性記憶部６３１、ゲームデータ記憶部６３２、優先度記憶部６３３および未通知イベント記憶部６３４は、図２の属性記憶部５３１、ゲームデータ記憶部５３２、優先度記憶部５３３および未通知イベント記憶部５３４と同一または類似であってよい。なお、ゲームデータ記憶部６３２に保存されるゲームデータは、ゲーム画面／音声データの生成に必要な素材データを含むこととする。

入力部６４１は、例えば前述の入力装置であってよく、プレイヤから操作を受け付ける。入力部６４１は、プレイヤの操作に基づいて操作データを生成する。入力部６４１は、ゲーム実行部６２０、例えばイベント制御部６２２へ、プレイヤの操作データを送る。

エンコーダ６４２は、前述のプロセッサおよびメモリ、または専用のハードウェア・エンコーダであってよい。エンコーダ６４２は、ゲーム画面／音声生成部６２５から、ゲーム画面／音声データを受け取り、これらをエンコードする。例えば、エンコーダ６４２は、ゲーム画面を既定のビデオコーデック（例えば、Ｈ．２６４、Ｈ．２６５、など）によりエンコードし、音声を既定の音声コーデック（例えば、ＡＡＣ（Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ））によりエンコードする。そして、エンコーダ６４２は、エンコード済みデータを例えばｍｐ４などの形式のマルチメディアコンテナとして送信部６１２へ送る。

出力部６４３は、前述の出力装置であってよい。出力部６４３は、ゲーム画面／音声生成部６２５からゲーム画面／音声データを受け取り、これらを出力する。すなわち、表示デバイスがゲーム画面を表示したり、スピーカがゲーム音声を出力したり、バイブレータが振動パターンに従って振動したりする。

なお、配信者端末６００の動作は、図７において説明した図２のゲームサーバ５００の動作例を適宜読み替えることで理解することができる。具体的には、配信者端末６００はプレイヤの操作を直接受け付ける点と、通知データを含むゲームプログラムの実行結果に基づいてゲーム画面／音声を生成し、これらを自ら出力すると共にエンコードして動画配信サーバ２００へアップロードする点とが、ゲームサーバ５００とは異なる。

以上説明したように、第２の実施形態に係る配信者端末は、単位期間内に発生するイベントのうち所定個数を上限に通知対象イベントを選択し、当該通知対象イベントの発生をプレイヤ、そして最終的には観客に通知する。故に、この配信者端末によれば、イベントの発生が短期間に集中した場合であっても所定個数を限度に通知が行われるので、プレイヤおよび観客がゲーム状態をある程度把握できるようにしながらも、プレイヤおよび観客に提供されるゲーム体験が破綻するのを回避することができる。また、通知に伴う配信者端末の負荷が一定の上限を超えて増加することはない。

（変形例）
上記実施形態ではいずれも、プレイヤおよび観客がゲーム状態をある程度把握できるように、通知対象イベントを制限している。しかしながら、通知対象から漏れたイベントも把握できるようにして欲しいというニーズも想定される。そこで、例えばゲーム画面外に、通知対象から漏れたイベント、または全イベントの情報、例えばどのイベントがいつ、どこで起きたか、などのリスト（イベントリストと称する）を表示する領域が設けられてもよい。かかるイベントリストは、ゲーム画面外に表示されるので、ゲーム画面を注視しているプレイヤやその他の観客の妨げとはならない。また、プレイヤおよび観客が個別に、かかるリストを自己の端末上に表示するかどうかを設定できるようにしてもよい。

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

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

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

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

１００，６００・・・配信者端末
２００・・・動画配信サーバ
３００・・・観客端末
４００・・・補助サーバ
５００・・・ゲームサーバ
５１０，６１０・・・通信部
５１１，６１１・・・受信部
５１２，６１２・・・送信部
５２０，６２０・・・ゲーム実行部
５２１，６２１・・・属性取得部
５２２，６２２・・・イベント制御部
５２３，６２３・・・通知対象選択部
５２４，６２４・・・通知データ生成部
６２５・・・ゲーム画面／音声生成部
５３１，６３１・・・属性記憶部
５３２，６３２・・・ゲームデータ記憶部
５３３，６３３・・・優先度記憶部
５３４，６３４・・・未通知イベント記憶部
６４１・・・入力部
６４２・・・エンコーダ
６４３・・・出力部

Claims (10)

1. ゲームのリアルタイムプレイ動画の観客の端末によって発行された当該ゲームに対する介入の実施要求を受信する補助サーバから、当該実施要求に基づくイベントの発生要求を受信する受信部と、
   少なくとも前記発生要求に応じて、前記ゲーム上で発生するイベントを制御するイベント制御部と、
   第１の期間内に前記ゲーム上で発生する第１のイベントのうち所定個数を上限に通知対象イベントを選択する選択部と、
   前記通知対象イベントの発生を前記ゲームのプレイヤに通知する通知データを生成する生成部と
   を具備する、ゲーム実行装置。
2. 前記選択部は、前記第１のイベントから前記所定個数を上限に優先度の降順に前記通知対象イベントを選択し、
   前記優先度は、イベントの種類毎に予め定義されている、
   請求項１に記載のゲーム実行装置。
3. 前記第１のイベントの要求者の属性を取得する取得部をさらに具備し、
   前記選択部は、前記第１のイベントのうち境界値以上の優先度を割り当てられたものが前記所定個数を超える場合に、前記境界値に等しい優先度を割り当てられた複数の第２のイベントのうちの一部を当該第２のイベントの要求者の属性に基づいて前記通知対象イベントとして選択し、
   前記境界値は、前記第１のイベントに割り当てられた優先度を降順にソートした場合に前記所定個数番目に並ぶ優先度に等しい、
   請求項２に記載のゲーム実行装置。
4. 前記要求者の属性は、当該要求者が前記リアルタイムプレイ動画の視聴を開始した時間を含む、請求項３に記載のゲーム実行装置。
5. 前記要求者の属性は、当該要求者が前記介入の実施を要求した時間を含む、請求項３に記載のゲーム実行装置。
6. 前記要求者の属性は、前記リアルタイムプレイ動画において当該要求者からの要求により前記ゲーム上で発生したイベントがいずれかの期間における通知対象イベントとして選択された回数を含む、請求項３に記載のゲーム実行装置。
7. 前記選択部は、前記第１のイベントのうち境界値以上の優先度を割り当てられたものが前記所定個数を超える場合に、前記境界値に等しい優先度を割り当てられた複数の第２のイベントのうちの一部を前記通知対象イベントとしてランダムに選択し、
   前記境界値は、前記第１のイベントに割り当てられた優先度を降順にソートした場合に前記所定個数番目に並ぶ優先度に等しい、
   請求項２に記載のゲーム実行装置。
8. 前記通知データは、前記通知対象イベントを表示するサブ画面を前記ゲームの画面に重畳するためのデータを含む、請求項１に記載のゲーム実行装置。
9. 前記選択部は、前記第１のイベントの数が前記所定個数を下回る場合には、前記第１の期間よりも過去の第２の期間内に前記ゲーム上で発生したイベントであって、当該第２の期間における通知対象イベントとして選択されなかったイベントを前記第１の期間における通知対象イベントとしてさらに選択する、請求項１に記載のゲーム実行装置。
10. コンピュータを、
    ゲームのリアルタイムプレイ動画の観客の端末によって発行された当該ゲームに対する介入の実施要求を受信する補助サーバから、当該実施要求に基づくイベントの発生要求を受信する手段、
    少なくとも前記発生要求に応じて、前記ゲーム上で発生するイベントを制御する手段、 第１の期間内に前記ゲーム上で発生する第１のイベントのうち所定個数を上限に通知対象イベントを選択する手段、
    前記通知対象イベントの発生を前記ゲームのプレイヤに通知する通知データを生成する手段
    として機能させるための、ゲームプログラム。