図面 (/)

技術 サーバおよびプログラム

出願人 株式会社ドワンゴ
発明者 川上量生千野裕司
出願日 2018年3月13日 (1年9ヶ月経過) 出願番号 2018-045379
公開日 2019年9月19日 (2ヶ月経過) 公開番号 2019-154780
状態 特許登録済
技術分野 電子ゲーム機 計算機間の情報転送
主要キーワード 負荷指標 人工生命 受信要求情報 実行負荷 ミュージックプレイヤー 実況音声 中間パラメータ エンコード済みデータ
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2019年9月19日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (12)

課題

ゲームのリアルタイムプレイ動画観客による当該ゲームの進行へ介入短期間に集中することによる双方向的ゲーム体験破綻を回避する。

解決手段

本発明の一態様に係るサーバは、算出部と、決定部と、送信部と、介入部とを含む。算出部は、プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する。決定部は、ゲームのリアルタイムプレイ動画の観客がゲームに対して介入を実施するための対価を負荷指標に基づいて決定する。送信部は、対価を示す情報を観客の端末へ送信する。介入部は、介入の実施要求が受信された場合に、対価と引き替えにゲームに対して当該実施要求の対象となる介入を実施する。決定部は、負荷指標が第1の負荷を示す場合には対価を第1の値に決定し、負荷指標が第1の負荷よりも重い第2の負荷を示す場合には対価を第1の値よりも高い第2の値に決定する。

概要

背景

ビデオゲームは、スタンドアローン(Stand Alone)型、またはオンラインゲーム(例えば、クラウドゲーム、MO(Multiplayer Online)ゲーム、MMO(Massively Multiplayer Online)ゲーム)に大別することができる。また、オンラインゲームは、C/S(Client / Server)型およびP2P(Peer to Peer)型にさらに分類することができる。スタンドアローン型のゲームおよびP2P型のオンラインゲームは、プレイヤ端末ゲームプログラムを実行することで実現され、1人ないし高々数十人程度のプレイヤがプレイする。他方、特にC/S型では、プレイヤの端末に接続されたゲームサーバがゲームプログラムの一部(サーバサイドプログラム)を実行することで実現され、MMO型のゲームでは数百人から数百万人ものプレイヤがネットワーク同時接続してプレイすることができる。

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

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

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

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

概要

ゲームのリアルタイムプレイ動画の観客による当該ゲームの進行へ介入短期間に集中することによる双方向的なゲーム体験の破綻を回避する。本発明の一態様に係るサーバは、算出部と、決定部と、送信部と、介入部とを含む。算出部は、プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する。決定部は、ゲームのリアルタイムプレイ動画の観客がゲームに対して介入を実施するための対価を負荷指標に基づいて決定する。送信部は、対価を示す情報を観客の端末へ送信する。介入部は、介入の実施要求が受信された場合に、対価と引き替えにゲームに対して当該実施要求の対象となる介入を実施する。決定部は、負荷指標が第1の負荷を示す場合には対価を第1の値に決定し、負荷指標が第1の負荷よりも重い第2の負荷を示す場合には対価を第1の値よりも高い第2の値に決定する。

目的

本発明は、ゲームのリアルタイムプレイ動画の観客による当該ゲームの進行へ介入が短期間に集中することによる双方向的なゲーム体験の破綻を回避することを目的とする

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する算出部と、前記ゲームのリアルタイムプレイ動画観客が前記ゲームに対して介入を実施するための対価を前記負荷指標に基づいて決定する決定部と、前記対価を示す情報を前記観客の端末へ送信する送信部と、前記端末から前記介入の実施要求を受信する受信部と、前記介入の実施要求が受信された場合に、前記対価と引き替えに前記ゲームに対して当該実施要求の対象となる介入を実施する介入部とを具備し、前記決定部は、前記負荷指標が第1の負荷を示す場合には前記対価を第1の値に決定し、前記負荷指標が前記第1の負荷よりも重い第2の負荷を示す場合には前記対価を前記第1の値よりも高い第2の値に決定する、サーバ

請求項2

前記算出部は、前記負荷指標を算出する以前の単位期間内に受信された前記実施要求に基づいて、前記負荷指標を算出する、請求項1に記載のサーバ。

請求項3

前記算出部は、前記単位期間に受信された前記実施要求の数に基づいて、前記負荷指標を算出する、請求項2に記載のサーバ。

請求項4

前記算出部は、前記単位期間に受信された前記実施要求に割り当てられた介入重みに基づいて、前記負荷指標を算出する、前記介入重みは、前記実施要求の対象となる介入の種類毎に予め定義される、請求項2に記載のサーバ。

請求項5

第1の種類の介入の実施要求に割り当てられる前記重みは、第2の種類の介入の実施要求に割り当てられる前記重みに比べて大きく、前記第1の種類の介入の実施により生じる負荷は、前記第2の種類の介入の実施により生じる負荷よりも重い、請求項4に記載のサーバ。

請求項6

前記算出部は、前記負荷指標を算出する以前のある時点において前記ゲームのプレイ画面に描画されるオブジェクトに割り当てられたオブジェクト重みに基づいて、前記負荷指標を算出し、前記オブジェクト重みは、前記オブジェクトの種類毎に予め定義される、請求項1に記載のサーバ。

請求項7

前記算出部は、前記負荷指標を周期的に算出し、前記決定部は、前記対価を前記負荷指標に基づいて周期的に決定し、前記送信部は、前記端末へ前記対価を示す情報を周期的に送信し、前記端末は、前記対価を示す情報を受信する度に最新の対価を画面に表示する、請求項1に記載のサーバ。

請求項8

前記決定部は、前記対価の中間パラメータである変動比率を前記負荷指標に基づいて決定し、前記送信部は、前記端末に、前記対価を示す情報として前記変動比率を送信し、前記対価は、当該対価に対応する介入の種類に対して予め定義された基準対価に前記変動比率を乗じた値である、請求項1に記載のサーバ。

請求項9

プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する算出部と、前記ゲームのリアルタイムプレイ動画の観客が前記ゲームに対して介入を実施するための所要人数を前記負荷指標に基づいて決定する決定部と、前記所要人数を示す情報を前記観客の端末へ送信する送信部と、前記端末から前記介入の実施要求を受信する受信部と、前記所要人数以上の観客の端末から前記介入の実施要求が受信された場合に、前記ゲームに対して当該実施要求の対象となる介入を実施する介入部とを具備し、前記決定部は、前記負荷指標が第1の負荷を示す場合には前記所要人数を第1の値に決定し、前記負荷指標が前記第1の負荷よりも重い第2の負荷を示す場合には前記所要人数を前記第1の値よりも多い第2の値に決定する、サーバ。

請求項10

コンピュータを、プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する手段、前記ゲームのリアルタイムプレイ動画の観客が前記ゲームに対して介入を実施するための対価を前記負荷指標に基づいて決定する手段、前記対価を示す情報を前記観客の端末へ送信する手段、前記端末から前記介入の実施要求を受信する手段、前記介入の実施要求が受信された場合に、前記対価と引き替えに前記ゲームに対して当該実施要求の対象となる介入を実施する手段として機能させるためのプログラムであって、前記決定する手段は、前記負荷指標が第1の負荷を示す場合には前記対価を第1の値に決定し、前記負荷指標が前記第1の負荷よりも重い第2の負荷を示す場合には前記対価を前記第1の値よりも高い第2の値に決定する、プログラム。

請求項11

コンピュータを、プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する手段、前記ゲームのリアルタイムプレイ動画の観客が前記ゲームに対して介入を実施するための所要人数を前記負荷指標に基づいて決定する手段、前記所要人数を示す情報を前記観客の端末へ送信する手段、前記端末から前記介入の実施要求を受信する手段、前記所要人数以上の観客の端末から前記介入の実施要求が受信された場合に、前記ゲームに対して当該実施要求の対象となる介入を実施する手段として機能させるためのプログラムであって、前記決定する手段は、前記負荷指標が第1の負荷を示す場合には前記所要人数を第1の値に決定し、前記負荷指標が前記第1の負荷よりも重い第2の負荷を示す場合には前記所要人数を前記第1の値よりも多い第2の値に決定する、プログラム。

技術分野

0001

本発明は、双方向的ゲーム体験を提供するゲームのリアルタイムプレイ動画の配信システムに関する。

背景技術

0002

ビデオゲームは、スタンドアローン(Stand Alone)型、またはオンラインゲーム(例えば、クラウドゲーム、MO(Multiplayer Online)ゲーム、MMO(Massively Multiplayer Online)ゲーム)に大別することができる。また、オンラインゲームは、C/S(Client / Server)型およびP2P(Peer to Peer)型にさらに分類することができる。スタンドアローン型のゲームおよびP2P型のオンラインゲームは、プレイヤ端末ゲームプログラムを実行することで実現され、1人ないし高々数十人程度のプレイヤがプレイする。他方、特にC/S型では、プレイヤの端末に接続されたゲームサーバがゲームプログラムの一部(サーバサイドプログラム)を実行することで実現され、MMO型のゲームでは数百人から数百万人ものプレイヤがネットワーク同時接続してプレイすることができる。

0003

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

0004

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

0005

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

0006

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

先行技術

0007

特開2016−189804号公報
特開2014−76176号公報

発明が解決しようとする課題

0008

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

0009

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

0010

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

0011

観客による介入を無条件に実現するのではなく、何らかの必要条件(例えば課金)を設ければ観客による介入は減るであろう。しかしながら、この必要条件が厳しすぎると、ごく一部の熱心な観客だけがゲームの進行に介入し、他の多くの観客はゲームの進行に介入しようとせず一体感が薄れる、といった事態が起こる可能性がある。他方、この必要条件が緩すぎると、無条件とした場合と同様の問題が起こる可能性がある。

0012

特許文献2には、ユーザが所望するオブジェクト対価を設定するための態様として、ゲーム制御装置の処理負荷に関する情報に基づいて、処理負荷が高いほど所定の対価が多く必要になるように設定すること([0013])、および、検索料あるいは検索条件に関する情報をユーザに提示すること([0051]、[0080]、図11、図16)、などが記載されている。しかしながら、特許文献2では、ゲームのリアルタイムプレイ動画の観客による当該ゲームの進行へ介入を許容することがそもそも想定されていない。

0013

本発明は、ゲームのリアルタイムプレイ動画の観客による当該ゲームの進行へ介入が短期間に集中することによる双方向的なゲーム体験の破綻を回避することを目的とする。

課題を解決するための手段

0014

本発明の一態様に係るサーバは、算出部と、決定部と、送信部と、受信部と、介入部とを含む。算出部は、プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する。決定部は、ゲームのリアルタイムプレイ動画の観客がゲームに対して介入を実施するための対価を負荷指標に基づいて決定する。送信部は、対価を示す情報を観客の端末へ送信する。受信部は、端末から介入の実施要求を受信する。介入部は、介入の実施要求が受信された場合に、対価と引き替えにゲームに対して当該実施要求の対象となる介入を実施する。決定部は、負荷指標が第1の負荷を示す場合には対価を第1の値に決定し、負荷指標が第1の負荷よりも重い第2の負荷を示す場合には対価を第1の値よりも高い第2の値に決定する。

0015

本発明の別の態様に係るサーバは、算出部と、決定部と、送信部と、受信部と、介入部とを含む。算出部は、プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する。決定部は、ゲームのリアルタイムプレイ動画の観客がゲームに対して介入を実施するための所要人数を負荷指標に基づいて決定する。送信部は、所要人数を示す情報を観客の端末へ送信する。受信部は、端末から介入の実施要求を受信する。介入部は、所要人数以上の観客の端末から介入の実施要求が受信された場合に、ゲームに対して当該実施要求の対象となる介入を実施する。決定部は、負荷指標が第1の負荷を示す場合には所要人数を第1の値に決定し、負荷指標が第1の負荷よりも重い第2の負荷を示す場合には所要人数を第1の値よりも多い第2の値に決定する。

発明の効果

0016

本発明によれば、ゲームのリアルタイムプレイ動画の観客による当該ゲームの進行へ介入が短期間に集中することによる双方向的なゲーム体験の破綻を回避することができる。

図面の簡単な説明

0017

実施形態に係る補助サーバを含む、ゲームのリアルタイムプレイ動画の配信システムの一例を示すブロック図。
図1の変形例を示す図。
図1中の補助サーバを例示するブロック図。
図2の補助サーバの対価決定に関する動作の概念図。
介入重みテーブルを例示する図。
オブジェクト重みテーブルを例示する図。
ある時点で観客に提示される対価を例示する図。
図7Aとは別の時点で観客に提示される対価を例示する図。
図2の補助サーバの動作を例示するフローチャート
実施形態の変形例において、ある時点で観客に提示される所要人数を例示する図。
実施形態の変形例において、図9Aとは別の時点で観客に提示される所要人数を例示する図。

実施例

0018

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

0019

(実施形態)
実施形態に係る補助サーバは、図1に例示される、ゲームのリアルタイムプレイ動画の配信システムに組み込むことができる。この配信システムは、配信者端末100と、動画配信サーバ200と、観客端末300−1,300−2,・・と、補助サーバ400と、ゲームサーバ500とを含む。

0020

図1の例では、動画配信サーバ200は、配信者端末100(クライアント)およびゲームサーバ500(サーバ)において実行されるC/S型のオンラインゲームのリアルタイムプレイ動画を、観客端末300(および配信者端末100)へ配信する。

0021

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

0022

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

0023

後者の例では、配信者端末100は、ゲーム画面の描画および出力音声を決定するために、ゲームの素材データ、例えば、オブジェクト(具体的には、キャラクタ、アイテム、背景、ビジュアルエフェクト(visual effect)、など)の画像データ、効果音(SE:Sound Effect)、BGM(background music)、キャラクターボイス(Character Voice)、などの音声データ、振動パターン、などを主記憶または補助記憶装置に保存しておく必要がある。

0024

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

0025

配信者端末100は、ゲームプログラム(クライアントサイドプログラム)が実行可能なコンピュータなどの電子デバイス、例えば、PC(Personal Computer)、モバイル端末(例えば、タブレットスマートフォンラップトップフィーチャーフォンポータブルゲーム機デジタルミュージックプレイヤー電子書籍リーダなど)、VR(Virtual Reality)端末、AR(Augmented Reality)端末、ゲーム機、テレビ受像機インターネットテレビを含む)、などであり得るが、これらに限られない。

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

補助サーバ400は、ゲームの実行に関わる負荷を示す負荷指標を算出し、当該負荷指標に基づいて対価を決定し、当該対価を示す情報を観客端末300へ送信する。なお、ゲームの実行に関わる負荷の詳細については後述する。ここで、補助サーバ400は、負荷指標の示す負荷が重いほど高くなるように対価を決定する。故に、負荷が重い時には介入がしづらくなるので、負荷のさらなる増大が抑制される。すなわち、プレイヤおよび観客の認知能力を超えてゲーム状態が複雑になることによる双方向的なゲーム体験の破綻、および/またはゲーム実行装置におけるゲームプログラムの実行負荷が過大になることを回避できる。他方、負荷が軽い時には介入がしやすくなるので、介入が話題作りの役割を果たし、観客間、または観客−配信者(プレイヤ)間のコミュニケーションが促進され、双方向性の高いゲーム体験を提供することが可能となる。例えば、観客からの介入が減って盛り上がり欠ける場面で観客からの介入を呼び込めるので、プレイヤ/観客のプレイ/視聴のモチベーションを保ちやすくなる。また、介入を積極的にしたいが対価の支払いを節約したい観客を、負荷が小さいと期待されるプレイ動画、例えば観客数やコメント数の少ないプレイ動画へ誘導するという効果も期待できる。

0033

ゲームサーバ500は、配信者端末100および補助サーバ400とネットワーク経由で接続しており、互いにデータを送受信できる。ゲームサーバ500は、ゲームプログラムを実行する。図1の例においてゲームサーバ500は、ゲーム実行装置と呼ぶことができる。

0034

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

0035

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

0036

図2には、ゲームのリアルタイムプレイ動画の配信システムの別の例が示される。この配信システムは、配信者端末600と、動画配信サーバ200と、観客端末300−1,300−2,・・と、補助サーバ400とを含む。

0037

図2の例では、動画配信サーバ200は、配信者端末600において実行されるスタンドアローン型のゲームまたはP2P型のオンラインゲームのリアルタイムプレイ動画を、観客端末300(および配信者端末600)へ配信する。

0038

図2の動画配信サーバ200、観客端末300および補助サーバ400は、図1の動画配信サーバ200、観客端末300および補助サーバ400と同一であり得る。ただし、図1に関する説明における「配信者端末100」および「ゲームサーバ500」を「配信者端末600」に置き換える必要がある。

0039

配信者端末600は、ゲームプログラムを実行する。また、配信者端末600は、ゲームの素材データをその主記憶または補助記憶装置に保存しているものとする。図2の例において配信者端末600は、ゲーム実行装置と呼ぶことができる。

0040

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

0041

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

0042

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

0043

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

0044

以下、図3乃至図8を用いて、補助サーバ400について詳しく説明する。
補助サーバ400は、コンピュータであって、例えば、入出力制御通信制御、そして介入制御(すなわち、介入の実施、決済の制御、後述される負荷指標の算出、対価の決定、など)を行うプロセッサを含む。ここで、プロセッサは、典型的にはCPU(Central Processing Unit)および/またはGPU(Graphics Processing Unit)であるが、マイコンFPGA(Field Programmable Gate Array)、またはDSP(Digital SignalProcessor)、などであってもよい。また、補助サーバ400は、かかる処理を実現するためにプロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータなどを一時的に格納するメモリを含んでいる。

0045

なお、補助サーバ400は、全てのデータをオンメモリの状態で扱ってもよいし、一部のデータが補助記憶装置に退避されていてもよい。補助記憶装置は、例えば、補助サーバ400に内蔵または外付けされたHDD(Hard Disc Drive)、SSD(Solid State Drive)、フラッシュメモリなどであってもよいし、補助サーバ400からアクセス可能データベースサーバであってもよい。

0046

また、補助サーバ400は、複数のコンピュータの組み合わせであってよい。例えば、補助サーバ400の機能部、例えば後述される通信部410と介入制御部420および種々の記憶部とが別個のコンピュータに分散して実装されてもよい。

0047

補助サーバ400は、さらに、ネットワークに接続するための通信I/F(インタフェース)を利用可能である。通信I/Fは、補助サーバ400に内蔵されてもよいし、補助サーバ400に外付けされてもよい。

0048

通信I/Fは、ネットワーク経由で、観客端末300およびゲーム実行装置(図1の例ではゲームサーバ500であり、図2の例では配信者端末600である)と通信をするためのモジュールであり得る。例えば、通信I/Fは、観客端末300から介入の実施要求を受信したり、この実施要求に基づくイベント発生要求などの種々の要求をゲーム実行装置へ送信したりする。また、通信I/Fは、ゲーム実行装置から、例えばゲームのプレイ画面に描画されるオブジェクト(の種類)を示すデータ(後述される)を受信し得る。

0049

次に、図3を用いて補助サーバ400の構成例の説明を続ける。図3の補助サーバ400は、通信部410と、介入制御部420と、種々の記憶部とを含む。

0050

通信部410は、例えば前述の通信I/Fであってよく、ネットワーク経由で、例えば観客端末300からデータを受信したり、ゲーム実行装置へデータを送信したりする。具体的には、通信部410は、受信部411および送信部412を含む。

0051

受信部411は、観客端末300から介入の実施要求を受信する。ここで、介入の実施要求は、例えば要求する介入の種類を示すデータと、当該要求の主体である観客(以降、要求者と呼ぶ)を示すデータと、当該要求の発行時に要求者の観客端末300の画面に表示されていた対価、すなわち要求者が支払いに同意した対価を示すデータとを含み得る。以降の説明において、イベントおよびサブイベントは区別せず、いずれもイベントと称する。対価を示すデータは、当該対価または中間パラメータの値を直接的に示すものであってもよいし、いつ決定/通知された対価か、または何番目に決定/通知された対価かを示すものであってもよい。

0052

また、受信部411は、ゲーム実行装置から、ゲームのプレイ画面に描画されるオブジェクトを示すデータを受信し得る。このデータは、例えば対象となるオブジェクトそれぞれの種類(或いは必要であれば個体)を識別する識別子であり得る。前述のように、オブジェクトは、キャラクタ、アイテム、背景、ビジュアルエフェクトなどを含み得る。さらに、受信部411は、図示されない決済サーバから対価の決済応答を受信し得る。決済応答は、決済が成功したか失敗したかを示すコードを含み得る。

0053

受信部411は、これらの受信データを介入制御部420へ送る。具体的には、受信部411は、介入の実施要求を介入実施部421へ送り、オブジェクトを示すデータを負荷指標算出部423へ送り、決済応答を決済制御部422へ送る。

0054

送信部412は、対価決定部424から対価を示す情報を受け取り、これを観客端末300へ送る。かかる情報は、観客端末300へ直接送信されてもよいし、動画配信サーバ200などを経由して観客端末300へ送信されてもよい。対価を示す情報の詳細は、後述されるが、個別の介入についての対価の値を示してもよいし、個別の介入についての対価を一意に算出するための中間パラメータの値を示してもよい。また、送信部412は、介入実施部421から介入の実施要求の受理拒否を示す応答を受け取り、これを要求者の観客端末300へ送ってもよい。

0055

さらに、送信部412は、介入実施部421からゲーム実行装置に対する要求、例えばイベント発生要求を受け取り、これをゲーム実行装置へ送る。また、送信部412は、決済制御部422から対価の決済要求を受け取り、これを図示されない決済サーバへ送り得る。

0056

介入制御部420は、前述のプロセッサおよびメモリであってよい。介入制御部420は、通信部410から、介入の実施要求、オブジェクトを示すデータ、対価の決済応答、などのデータを受け取る。また、介入制御部420は、種々の記憶部から必要なデータを読み出す。介入制御部420は、通信部410から受け取ったデータおよび/または種々の記憶部から読み出したデータに基づいて、介入を実施したり、対価を決定したり、図示されない決済サーバに対価の決済を要求したりする。さらに、介入制御部420は、ゲーム実行装置への種々の要求、決定した対価を示す情報、対価の決済要求、介入の実施要求の受理/拒否を示す応答、などの種々のデータを通信部410へ送る。具体的には、介入制御部420は、介入実施部421と、決済制御部422と、負荷指標算出部423と、対価決定部424とを含む。

0057

介入実施部421は、受信部411から介入の実施要求を受け取ると、対価と引き替えにゲームに対して当該実施要求の対象となる介入を実施する。まず、介入実施部421は、対価の決済を行うために、介入の実施要求を決済制御部422へ送る。介入実施部421は、それから、決済制御部422から決済に失敗/成功したとの報告を受ける。

0058

介入実施部421は、決済制御部422から決済に成功したとの報告を受けると、介入の実施要求に応じた要求、例えばイベントの発生要求を生成し、送信部412へ送る。また、介入実施部421は、介入が実施されることをその要求者に伝えるために、介入の実施要求の受理を示す応答を生成し、送信部412へ送ってもよい。さらに、後述されるように、受信済みの介入の実施要求の情報に基づいて負荷指標を算出する場合には、介入実施部421は、かかる情報を受信要求情報記憶部431に書き込む。

0059

介入実施部421は、決済制御部422から決済に失敗したとの報告を受けると、介入を取り止める。また、介入実施部421は、介入が実施されないことをその要求者に伝えるために、介入の実施要求の拒否を示す応答を生成し、送信部412へ送ってもよい。ここで、決済の失敗には様々な理由が想定される。そこで、介入実施部421は、この応答に介入の実施要求が拒否された理由を示すデータを含めてもよい。例えば、決済の失敗を報告する場合に、要求者の保有する財貨が対価に満たない(すなわち残高不足)、実施要求に含まれるデータの示す対価(以降、申告対価と称する)が不正である、などの理由が想定される。これらの理由は、決済制御部422が決済の失敗と一緒に介入実施部421へ報告し得る。

0060

決済制御部422は、介入実施部421から介入の実施要求を受け取る。決済制御部422は、対価記憶部433からこの実施要求の対象となる介入の対価の履歴を読み出し、この実施要求の申告対価が適正であるか否かを判定する。例えば、申告対価が、過去に決定されたいずれの対価とも一致しない場合や、古すぎる場合(例えば2つ以上前に決定された対価である場合、所定時間以上前に決定された対価である場合、など)には、決済制御部422は、申告対価が不正であるため決済に失敗したと介入実施部421に報告してもよい。

0061

他方、決済制御部422は、申告対価が適正であると判定した場合には、当該申告対価の決済を図示されない決済サーバに要求してもよい。具体的には、決済制御部422は、対価の決済要求を送信部412へ送り、そして、受信部411からこの決済要求に対する決済応答を受け取ってもよい。そして、決済制御部422は、決済応答に基づいて決済に成功したか失敗したかを判定し、その結果を介入実施部421に報告してもよい。

0062

なお、決済処理は、決済サーバの代わりに補助サーバ400またはその他のサーバによって行われてもよい。

0063

負荷指標算出部423は、(1)負荷指標を算出する以前の単位期間内に受信済みの介入の実施要求の情報(以降、単に受信要求情報と称する)、および(2)負荷指標を算出する以前のある時点においてゲームのプレイ画面に描画されるオブジェクト、のうちの一方または両方に基づいて、プレイ中のゲームの実行に関わる負荷を示す負荷指標を算出する。このほか、重み記憶部432は、ゲーム実行装置から例えば、CPU使用率メモリ使用量などの情報を取得し、当該情報を考慮して負荷指標を算出してもよい。負荷指標算出部423は、算出した負荷指標を対価決定部424へ送る。

0064

負荷指標算出部423は、負荷の短期間の変動に対価を追従させるために、負荷指標を周期的に、例えば数十秒おき、数分おき、程度に算出してもよい。なお、周期は、固定であってもよいし、可変であってもよい。この周期は、上記単位期間と一致してもよいし、しなくてもよい。

0065

ここで、負荷、とは、ゲーム実行装置におけるゲームプログラムの実行負荷と捉えることもできるが、プレイヤおよび観客のゲーム状態の認知負荷と捉えることもできる。前者の負荷は、ゲーム実行装置のハードウェア能力の増強により、殆ど問題とならなくなる可能性もある。他方、人間のゲーム状態に関する認知能力は本人の情報処理能力や当該ゲームのプレイ経験に応じてある程度異なると考えられるものの、生理的な限界は存在する。故に、ゲーム実行装置のハードウェア能力が十分に高い場合であっても、後者の負荷が過度に大きくならないように、観客の介入に歯止めをかけることには意義がある。

0066

まず、上記(1)の場合の負荷指標算出部423の動作について説明する。負荷指標算出部423は、受信要求情報記憶部431から受信要求情報を受け取る。ここで、受信要求情報は、例えば、(1−1)単位期間内に受信された介入の実施要求の数をカウントした値であってもよいし、(1−2)単位期間内に受信された介入の実施要求それぞれの対象となる介入の種類を示すデータであってもよい。

0067

上記(1−1)について、負荷指標算出部423は、実施要求の数をそのまま負荷指標としてもよいし、または何らかの数式に代入して負荷指標を算出してもよい。例えば、数式は、統計値を計算するものであってよい。実施要求の数が多いほどより多くの介入がゲームに対して実施されるので、負荷指標算出部423は、より重い負荷を示す負荷指標を算出する。

0068

上記(1−2)について、負荷指標算出部423は、実施要求のそれぞれに割り当てられた介入重みを重み記憶部432から読み出す。この介入重みは、実施要求の対象となる介入の種類毎に予め定義されて、介入の種類に対応付けて重み記憶部432に保存されている。故に、負荷指標算出部423は、受信要求情報の示す各実施要求の介入の種類をキーとして、当該実施要求に割り当てられた介入重みを重み記憶部432から読み出すことができる。重み記憶部432は、介入重みの総和を負荷指標としてもよいし、または他の何らかの数式に代入して負荷指標を算出してもよい。例えば、数式は、統計値を計算するものであってよい。

0069

ここで、介入重みは、例えば、より重い負荷を生じさせる介入にはより大きな値が定義されてよい。例えば、第1の種類の介入の実施により生じる負荷は、第2の種類の介入の実施により生じる負荷よりも重いとする。この場合に、第1の種類の介入の実施要求に割り当てられる介入重みは、第2の種類の介入の実施要求に割り当てられる介入重みに比べて大きく定義され得る。実施要求に割り当てられた重みが大きいほどゲームに対してより重い負荷の介入が実施されるので、負荷指標算出部423は、より重い負荷を示す負荷指標を算出する。

0070

介入の種類とその介入重みとを対応付ける介入重みテーブルの一例を図5に示す。図5において、介入重みは、3(最高)から1(最低)までの3段階で付与されている。故に、単位期間内に、「フード(低価値)をフィールドに投下する」ことの実施要求(介入重み1)と、「オブジェクト(高価値)をフィールドに投下する」ことの実施要求(介入重み2)と、「新しい人工生命体をフィールドに投下する」ことの実施要求(介入重み3)とが受信されたとすれば、負荷指標算出部423は、例えばこれらの総和である「6」を負荷指標として算出してもよい。なお、図5は例示に過ぎないので、介入重みを図5と異なるように割り当てることも可能である。

0071

次に、上記(2)の場合の負荷指標算出部423の動作について説明する。負荷指標算出部423は、受信部411から、ある時点においてゲームのプレイ画面に描画されるオブジェクトを示すデータを受け取る。そして、負荷指標算出部423は、オブジェクトのそれぞれに割り当てられたオブジェクト重みを重み記憶部432から読み出す。このオブジェクト重みは、オブジェクトの種類(または個体)毎に予め定義されて、オブジェクトに対応付けて重み記憶部432に保存されている。故に、負荷指標算出部423は、受信部411から受け取ったデータの示すオブジェクトの種類をキーとして、当該オブジェクトに割り当てられたオブジェクト重みを重み記憶部432から読み出すことができる。重み記憶部432は、オブジェクト重みの総和を負荷指標としてもよいし、または他の何らかの数式に代入して負荷指標を算出してもよい。例えば、数式は、統計値を計算するものであってよい。

0072

ここで、オブジェクト重みは、例えば、より重い負荷を生じさせるオブジェクトにはより大きな値が定義されてよい。例えば、ゲームのプレイ画面にある第1の種類のオブジェクトが存在することで生じる負荷(例えば、管理/描画負荷であってもよいし、人間の認知負荷であってもよい)は、同画面に第2の種類のオブジェクトが存在することで生じる負荷よりも重いとする。この場合に、第1の種類のオブジェクトに割り当てられるオブジェクト重みは、第2の種類のオブジェクトに割り当てられるオブジェクト重みに比べて大きく定義され得る。オブジェクトに割り当てられた重みが大きいほどゲームのプレイ画面の管理/描画/認知負荷が重くなるので、負荷指標算出部423は、より重い負荷を示す負荷指標を算出する。

0073

オブジェクトの種類とそのオブジェクト重みとを対応付けるオブジェクト重みテーブルの一例を図6に示す。図6において、オブジェクト重みは、5(最高)から1(最低)までの5段階で付与されている。故に、ある時点のゲームのプレイ画面に、2体の「プレイヤキャラクタ」(オブジェクト重み5)と、1体の「エネミーキャラクタ」(オブジェクト重み5)と、1つのアイテム(低価値)(オブジェクト重み1)とが描画されるとすれば、負荷指標算出部423は、例えばこれらの総和である「16」を負荷指標として算出してもよい。なお、図6は例示に過ぎないので、オブジェクト重みを図6と異なるように割り当てることも可能である。

0074

対価決定部424は、負荷指標算出部423から負荷指標を受け取り、これに基づいて対価を算出する。具体的には、対価決定部424は、負荷指標の示す負荷が重いほど高くなるように対価を決定する。例えば、負荷指標が第1の負荷を示す場合には対価を第1の値に決定し、負荷指標が第1の負荷よりも重い第2の負荷を示す場合には対価を第1の値よりも高い第2の値に決定してもよい。対価決定部424は、例えば、負荷指標の示す負荷の増加に対して単調増加するように(すなわち負荷の増加に対して減少しないように)対価を決定してもよい。なお、対価は、負荷の重さに対して線形に増加してもよいし、非線形(例えばステップ状)に増加してもよい。対価決定部424は、決定した対価を示す情報を送信部412へ送り、さらに対価記憶部433に書き込む。

0075

対価決定部424は、負荷指標に基づいて、介入の種類毎に対価を個別に決定してもよいが、代わりに、介入の種類間で共通の変動比率を決定してもよい。この変動比率は、対価の中間パラメータに相当する。この場合に、介入の種類毎の対価は、当該種類に予め定義された基準対価にこの変動比率をそれぞれ乗じることで一意に導出可能である。これにより、対価を更新する度に全種類の対価を通知せずとも変動比率を通知するだけで、観客端末300は全種類の対価について最新の値を表示できる(ただし、観客端末300において基準対価は既知であるとする)。これは、対価を示す情報の通知に関するオーバーヘッドの削減に寄与する。また、新たな種類の介入がゲームプログラムのアップデートなどにより追加される場合であっても、当該介入の対価を決定するための追加のプログラムコードを作成する必要はなく、新たな基準対価を定義するだけで済む。

0076

前述のように負荷指標算出部423が負荷指標を周期的に算出する場合には、対価決定部424も対価を周期的に決定してもよい。これにより、送信部412は対価を示す情報を観客端末300へ繰り返し送信し、観客端末300はかかる情報を受信する度に最新の対価を画面に表示できる。例えば、観客端末300の画面に、ある時には図7Aのような画面が表示され、別の時には図7Bのような画面が表示されるとする。これらは、いずれも、介入の実施要求を発行するためのGUI(Graphical User Interface)部品ウィジェット)として介入ボタンを含む介入メニュー画面を表す。図7Aおよび図7Bにおいて、介入ボタンは、実施要求を発行する対象となる介入と、その介入を実施するための対価とをそれぞれ示す。図7Aの例では、図7Bの例に比べて、それぞれの介入の対価が割安であることが看取できる。このように、観客は、対価の変動を見守りながら、自らが介入するタイミングを判断することができる。

0077

ただし、観客端末300が対価を示す情報を受信する度に最新の対価を画面に表示することは必須ではない。例えば、ゲームのリアルタイムプレイ動画を表示するページと、介入メニュー画面を表示するページとが異なっている場合には、観客が観客端末300を操作して後者の画面に遷移した時に受信済みの情報に基づいて最新の対価が表示されるようにしてもよい。また、補助サーバ400が対価を決定する度に全ての観客端末300に即時にこの対価を通知することも必須ではない。すなわち、観客が観客端末300を操作して介入メニュー画面を表示するページ画面に遷移した時に、観客端末300が対価の取得要求を補助サーバ400へ送信し、補助サーバ400がこれに応じて最新の対価を示す情報を返送するようにしてもよい。

0078

ここで、図4を用いて、補助サーバ400が対価の決定に関してどのように動作するかを概念的に説明する。図4の例では、負荷指標算出部423は、上記(1−1)の例に従って、負荷指標を算出することとする。

0079

受信部411は、単位期間T1に介入の実施要求を1つ受信する。負荷指標算出部423は、単位期間T1の終了後に、当該単位期間T1における要求受信数(1)に基づいて負荷指標を算出する。そして、対価決定部424は、この負荷指標に基づいて、対価の変動比率rを1に決定する。この変動比率を示す情報が観客端末300に通知され、観客端末300は通知された変動比率に基づいて対価を再計算し、画面上に最新の対価(100P)を表示する。

0080

同様に、受信部411は、単位期間T2に介入の実施要求を3つ受信する。負荷指標算出部423は、単位期間T2の終了後に、当該単位期間T2における要求受信数(3)に基づいて負荷指標を算出する。そして、対価決定部424は、この負荷指標に基づいて、対価の変動比率rを3に決定する。この変動比率を示す情報が観客端末300に通知され、観客端末300は通知された変動比率に基づいて対価を再計算し、画面上に最新の対価(300P)を表示する。

0081

図3の例において種々の記憶部は、受信要求情報記憶部431と、重み記憶部432と、対価記憶部433とを含む。これらの記憶部は、前述のメモリ単体であってもよいし、メモリおよび補助記憶装置の組み合わせであってもよい。

0082

受信要求情報記憶部431は、受信要求情報を保存する。受信要求情報は、介入実施部421によって書き込まれ、または書き換えられる。また、受信要求情報は、負荷指標算出部423によって読み出される。ただし、受信要求情報を負荷指標の算出において全く利用しないことも可能である(上記(2)の例)。この場合には、受信要求情報記憶部431は削除され得る。

0083

重み記憶部432は、例えば図5に示した介入重みテーブルの形式で、介入の種類に対応付けて介入重みを保存し、および/または、例えば図6に示したオブジェクト重みテーブルの形式で、オブジェクトの種類(または個体)に対応付けてオブジェクト重みを保存する。介入重みおよび/またはオブジェクト重みは、例えば補助サーバ400のプログラムのインストールまたはアップデート時に重み記憶部432に書き込まれ、または書き換えられ得る。介入重みおよび/またはオブジェクト重みは、負荷指標算出部423によって読み出される。

0084

ただし、介入重みおよびオブジェクト重みの一方または両方を負荷指標の算出において全く利用しないことも可能である。例えば、介入重みは上記(1−2)の例以外では不要となり得るし、オブジェクト重みは上記(2)の例以外では不要となり得る。また、上記(1−1)の例では、介入重みおよびオブジェクト重みの両方が不要となり得る。この場合には、重み記憶部432は削除され得る。

0085

対価記憶部433は、対価を示す情報を保存する。具体的には、対価記憶部433は、対価を示す情報に関連付けて、当該対価がいつ決定されたか、または何番目に決定されたかを示す情報も保存し得る。これらの情報は、決済制御部422が、申告対価が不正でないことを検査するために必要となり得る。対価を示す情報は、対価決定部424によって書き込まれ、または書き換えられ得る。対価を示す情報は、決済制御部422によって読み出される。

0086

次に、図8を用いて、1つの単位期間についての補助サーバ400の動作例を説明する。なお、図8の例では、負荷指標算出部423は、上記(1)の例に従って、負荷指標を算出することとする。

0087

まず、受信部411は観客端末300から介入の実施要求を受信すると(ステップS701)、介入実施部421は、決済制御部422と連携して、当該実施要求の対象となる介入を実施する(ステップS702)。ただし、介入実施部421は、対価の決済の成否次第で、実施要求を拒否し得る。かかる処理が単位期間の満了まで繰り返され(ステップS703)、処理はステップS704へ進む。他方、次の単位期間について図8の動作が並列的に開始し得る。すなわち、介入実施部421は、次の単位期間に受信した実施要求の対象となる介入を実施し始める。

0088

ステップS704において、負荷指標算出部423は、この単位期間に受信した介入の実施要求に基づいて、負荷指標を算出する。次に、対価決定部424は、ステップS704において算出された負荷指標に基づいて対価を決定する(ステップS705)。次に、送信部412は、ステップS705において決定された対価を示す情報を観客端末300へ送信する(ステップS706)。

0089

以上説明したように、実施形態に係る補助サーバは、ゲームの実行に関わる負荷を示す負荷指標を算出し、当該負荷指標に基づいて対価を決定し、当該対価を示す情報を観客端末へ送信する。より具体的には、補助サーバは、負荷指標の示す負荷が重いほど高くなるように対価を決定する。故に、負荷が重い時には介入がしづらくなるので、負荷のさらなる増大が抑制される。すなわち、プレイヤおよび観客の認知能力を超えてゲーム状態が複雑になることによる双方向的なゲーム体験の破綻、および/またはゲーム実行装置におけるゲームプログラムの実行負荷が過大になることを回避できる。他方、負荷が軽い時には介入がしやすくなるので、介入が話題作りの役割を果たし、観客間、または観客−配信者(プレイヤ)間のコミュニケーションが促進され、双方向性の高いゲーム体験を提供することが可能となる。例えば、観客からの介入が減って盛り上がりに欠ける場面で観客からの介入を呼び込めるので、プレイヤ/観客のプレイ/視聴のモチベーションを保ちやすくなる。また、介入を積極的にしたいが対価の支払いを節約したい観客を、負荷が小さいと期待されるプレイ動画、例えば観客数やコメント数の少ないプレイ動画へ誘導するという効果も期待できる。

0090

(変形例)
上記実施形態では、補助サーバは、負荷指標の示す負荷が重いほど高くなるように対価を決定する。ところで、介入に課される条件は対価に限られない。例えば、観客が○○人、この介入の実施を要求した場合に当該介入を実施する、というように、対価の代わりに介入を実施するための所要人数を条件としてもよい。本変形例では、対価の代わりにこの所要人数を変動させる。

0091

すなわち、変形例に係る補助サーバは、対価決定部424の代わりに図示されない所要人数決定部を備えている。そして、この所要人数決定部は、負荷指標の示す負荷が重いほど多くなるように所要人数を決定する。例えば、負荷指標が第1の負荷を示す場合には所要人数を第1の値に決定し、負荷指標が第1の負荷よりも重い第2の負荷を示す場合には所要人数を第1の値よりも多い第2の値に決定してもよい。

0092

また、変形例に係る補助サーバにおいて、送信部412は、対価の代わりに所要人数を示す情報を観客端末300へ送信することになる。この結果、例えば、観客端末300の画面に、ある時には図9Aのような画面が表示され、別の時には図9Bのような画面が表示されるとする。これらは、いずれも介入メニュー画面を表す。図9Aおよび図9Bにおいて、介入ボタンは、実施要求を発行する対象となる介入と、その介入を実施するための所要人数とをそれぞれ示す。

0093

さらに、変形例に係る補助サーバにおいて、決済に関する機能部、例えば決済制御部422は不要となり得る。また、介入実施部421は、受信部411によって、所要人数以上の観客端末300から介入の実施要求が受信された場合に、ゲームに対して当該実施要求の対象となる介入を実施することになる。

0094

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

0095

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

0096

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

0097

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

0098

100,600・・・配信者端末
200・・・動画配信サーバ
300・・・観客端末
400・・・補助サーバ
410・・・通信部
411・・・受信部
412・・・送信部
420・・・介入制御部
421・・・介入実施部
422・・・決済制御部
423・・・負荷指標算出部
424・・・対価決定部
431・・・受信要求情報記憶部
432・・・重み記憶部
433・・・対価記憶部
500・・・ゲームサーバ

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ