(57)【要約】【課題】成長度（レベル）の低い初心者などのユーザであっても、他ユーザを気にせずに対戦ゲームに参加し易くするビデオゲーム処理プログラムを提供する。【解決手段】複数のユーザが参加して共通の敵と戦うレイドバトルなどの対戦ゲームにおいて、参加ユーザのレベルの平均値や初心者の割合などに基づいて、対戦ゲームの環境（敵の強さや報酬の内容など）を決定する。例えば、レベルの平均値が低いほど、敵のヒットポイントを低く設定する。【選択図】図５
2018038555.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザのそれぞれによって操作されるユーザ端末に通信ネットワークを介して通信可能に接続され、複数のユーザが共通の敵と戦う対戦ゲームを含むゲームの進行を制御する機能をサーバに実現させるためのビデオゲーム処理プログラムであって、
前記サーバに、
前記ゲームにおける成長度を含むユーザ情報をユーザ毎に記憶部で管理するユーザ情報管理機能、
前記ユーザから前記対戦ゲームの参加を受け付ける受付機能、
前記対戦ゲームへの参加が受け付けられたユーザである参加ユーザの前記成長度の平均値を含む参加ユーザ情報を算出する算出機能、
前記参加ユーザ情報に基づいて前記対戦ゲームの環境を決定する環境決定機能、
を実現させるためのビデオゲーム処理プログラム。
【請求項２】
複数のユーザのそれぞれによって操作されるユーザ端末に通信ネットワークを介して通信可能に接続され、複数のユーザが共通の敵と戦う対戦ゲームを含むゲームの進行を制御する機能をサーバに実現させるためのビデオゲーム処理プログラムであって、
前記サーバに、
前記ゲームにおける成長度及び該ゲームにおけるプレイ時間を含むユーザ情報をユーザ毎に記憶部で管理するユーザ情報管理機能、
前記ユーザから前記対戦ゲームの参加を受け付ける受付機能、
前記対戦ゲームへの参加が受け付けられたユーザである参加ユーザの前記成長度及び前記プレイ時間の少なくとも一方に基づく該参加ユーザの初心者の割合を含む参加ユーザ情報を算出する算出機能、
前記参加ユーザ情報に基づいて前記対戦ゲームの環境を決定する環境決定機能、
を実現させるためのビデオゲーム処理プログラム。
【請求項３】
前記算出機能では、前記参加ユーザにおいて、前記成長度が所定範囲であり、且つ、前記プレイ時間が所定時間以上のユーザを初心者として前記割合を算出する機能、
を実現させるための請求項２に記載のビデオゲーム処理プログラム。
【請求項４】
前記サーバに、さらに、
前記成長度に関する前記参加ユーザの分布を表示させるための分布情報を生成し、該参加ユーザのそれぞれのユーザ端末に送信する分布情報送信機能、
を実現させるための請求項１〜３のいずれかに記載のビデオゲーム処理プログラム。
【請求項５】
前記環境決定機能では、前記環境として前記敵の強さに関係するパラメータを決定する機能、
を実現させるための請求項１〜４のいずれかに記載のビデオゲーム処理プログラム。
【請求項６】
前記環境決定機能では、前記環境として前記対戦ゲームにおいて前記参加ユーザに付与される報酬の内容を決定する機能、
を実現させるための請求項１〜５のいずれかに記載のビデオゲーム処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態の少なくとも１つは、複数のユーザが共通の敵と戦う対戦ゲームを含むゲームの進行を制御する機能をサーバに実現させるためのビデオゲーム処理プログラムに関する。
【背景技術】
【０００２】
近年、ソーシャルネットワーキングサービス（ＳＮＳ）上で提供される所謂ソーシャルゲームや、オンラインゲーム等では、メインのゲームとは別に、所謂レイドバトルと称されるコンテンツが提供されるゲームがある（例えば、特許文献１参照）。レイドバトルは、複数のユーザが共通の敵（レイドボス）と戦う対戦ゲームである。レイドバトルのような対戦ゲームは、参加条件を満たせば初心者（初級者）から上級者が参加可能である。そして、対戦ゲームに勝利した場合には特別な報酬が付与される場合もあり、ユーザは報酬獲得を１つの目的として対戦ゲームに参加する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１６−００５５７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述した複数のユーザが参加可能な対戦ゲームでは、様々なユーザが参加可能であるので、初心者のユーザの中には他ユーザの迷惑にならないか気になって対戦ゲームに参加しづらい場合もあった。
【０００５】
本発明の少なくとも１つの実施形態の目的は、関連する技術の不足を解決することである。
【課題を解決するための手段】
【０００６】
非限定的な観点によると、本発明に係るビデオゲーム処理プログラムは、複数のユーザのそれぞれによって操作されるユーザ端末に通信ネットワークを介して通信可能に接続され、複数のユーザが共通の敵と戦う対戦ゲームを含むゲームの進行を制御する機能をサーバに実現させるためのビデオゲーム処理プログラムであって、サーバに、ゲームにおける成長度を含むユーザ情報をユーザ毎に記憶部で管理するユーザ情報管理機能、ユーザから前記対戦ゲームの参加を受け付ける受付機能、対戦ゲームへの参加が受け付けられたユーザである参加ユーザの成長度の平均値を含む参加ユーザ情報を算出する算出機能、参加ユーザ情報に基づいて対戦ゲームの環境を決定する環境決定機能、を実現させるためのものである。
【発明の効果】
【０００７】
本願の各実施形態により１又は２以上の不足が解決される。
【図面の簡単な説明】
【０００８】
【図１】本発明の実施形態の少なくとも一つに対応するビデオゲーム処理システムの構成の例を示すブロック図である。
【図２】本発明の実施形態の少なくとも一つに対応するビデオゲーム処理サーバの構成を示すブロック図である。
【図３】本発明の実施形態の少なくとも一つに対応するユーザ情報を説明する説明図である。
【図４】本発明の実施形態の少なくとも一つに対応するユーザ端末の表示装置に表示される分布画像の一例を示す図である。
【図５】本発明の実施形態の少なくとも一つに対応するバトル処理の例を示すフローチャートである。
【図６】本発明の実施形態の少なくとも一つに対応するビデオゲーム処理サーバの構成を示すブロック図である。
【図７】本発明の実施形態の少なくとも一つに対応する報酬候補リストの一例を示す図である。
【図８】本発明の実施形態の少なくとも一つに対応するバトル処理の例を示すフローチャートである。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態の例について図面を参照して説明する。なお、以下で説明する各実施形態の例における各種構成要素は、矛盾等が生じない範囲で適宜組み合わせ可能である。また、ある実施形態の例として説明した内容については、他の実施形態においてその説明を省略している場合がある。また、各実施形態の特徴部分に関係しない動作や処理については、その内容を省略している場合がある。さらに、以下で説明する各種フローを構成する各種処理の順序は、処理内容に矛盾等が生じない範囲で順不同である。
【００１０】
［第１の実施形態］
図１は、本発明の一の実施形態におけるビデオゲーム処理システム１００の構成の例を示すブロック図である。図１に示すように、ビデオゲーム処理システム１００は、ビデオゲーム処理サーバ１０と、ビデオゲームをプレイする複数のユーザ（プレイヤ）がそれぞれ使用するユーザ端末２０，２０１〜２０Ｎ（Ｎは任意の整数）とを含む。ビデオゲーム処理サーバ１０と複数のユーザ端末２０，２０１〜２０Ｎとは、それぞれインターネットなどの通信ネットワーク３０に接続されている。なお、ビデオゲーム処理システム１００の構成はこれに限定されず、単一のユーザ端末を複数のプレイヤが使用する構成としてもよいし、複数のビデオゲーム処理サーバを備える構成としてもよい。
【００１１】
ビデオゲーム処理システム１００は、複数のユーザが参加可能な対戦ゲームが含まれるビデオゲームを実行する各種機能を有する。本実施形態の例の対戦ゲームは、所謂レイドバトルと称され、参加した各ユーザが操作するプレイヤキャラクタが、レイドボスと称される共通の敵と戦闘するゲームである。レイドボスは、例えば、ヒット（ライフ）ポイント（生命力のパラメータ）が非常に高く、ユーザが単独で戦って倒すことが難しいキャラクタである。本実施形態の例では、プレイヤキャラクタがレイドボスに攻撃を行ってヒットポイントを減らして所定値（例えば、ヒットポイントを０）にすることで、レイドボスが倒された（戦闘不能）状態となる。
【００１２】
本実施形態の例のレイドバトルには、例えば、所定の受付期間に参加要求を行ったユーザが参加できる。そして、受付期間の経過時にレイドバトルが開始される。
【００１３】
レイドボスを倒すことで、参加した各ユーザには、ゲーム内で使用可能なアイテムなどの特別な報酬が付与される。例えば、レイドバトル以外のゲームでは獲得するのが難しいアイテム等が報酬として付与される。なお、付与とは、アイテム等をユーザがゲーム内で使用可能な状態に設定されたことを意味する。本実施形態の例では、報酬は、各ユーザのユーザ情報（図３参照）に所有アイテムとして設定される。
【００１４】
また、本実施形態の例では、参加ユーザ情報に基づいて、レイドバトルの環境が決定される。参加ユーザ情報は、レイドバトルへの参加が受け付けられたユーザ（参加ユーザ）に関する情報である。参加ユーザ情報には、各プレイヤキャラクタ（参加ユーザ）のゲームでの成長度（習熟度）の平均値が含まれる。本実施形態の例のゲームでは、成長度がレベル（数値情報）として表現され、成長度の平均値としてレベルの平均値（レベル平均値）が算出される。プレイヤキャラクタのレベルは、敵などと戦う、課題を達成する等のゲームを進めていくことによって上昇（レベルアップ）していく。なお、レベルの上昇（変化）については、一般的な構成であるので詳細な説明は省略する。
【００１５】
また、レイドバトルの環境は、ゲームフィールドの種類及び大きさ、敵の強さ、報酬の内容、バトルの制限時間などが含まれる。本実施形態の例のレイドバトルでは、レイドボスの強さ（環境）が、参加ユーザのレベル平均値に基づいて決定される。
【００１６】
レイドボスの強さは、レイドボスに対応付けられているヒットポイント、攻撃力、防御力などの強さに関連するパラメータや、攻撃の種類などが含まれる。本実施形態の例では、レベル平均値が低くなるほど、レイドボスのヒットポイントの最大値を低くする。ヒットポイントが低いほど、参加ユーザの攻撃力が低くてもレイドボスを倒し易くなる。そのため、レベルの低い初心者のユーザが多く参加してる場合であっても、レイドボスを倒せる可能性が高くなる。
【００１７】
例えば、レイドボスが倒し易ければ、繰り返しレイドボスバトルに参加して多くの報酬を獲得することも可能となる。したがって、レベル平均値を低下させるレベルの低い初心者のユーザであっても歓迎され、バトルに参加し易い。なお、本実施形態の例における報酬の内容は、例えば、レイドボスの種類や抽選によって決定される。
【００１８】
なお、レイドボスとの対戦の方式は、コマンドを選択して攻撃等させるコマンドバトルなどのいずれの方式を採用してもよい。また、レイドバトルの進行は一般的な構成であるので詳細な説明は省略する。
【００１９】
ビデオゲーム処理サーバ１０は、ビデオゲーム処理システム１００の管理者によって管理され、ユーザ端末２０，２０１〜２０Ｎに対してビデオゲームに関する情報を提供するための各種の機能を有する。例えば、ユーザ端末２０，２０１〜２０Ｎの表示装置で表示させるための上記ビデオゲームのゲーム画像の情報を提供する。本実施形態の例において、ビデオゲーム処理サーバ１０は、ＷＷＷサーバなどの情報処理装置によって構成され、ユーザ情報などの各種情報を格納するデータベース１２（図３参照）を備える。
【００２０】
図２は、ビデオゲーム処理サーバ１０の構成の例であるビデオゲーム処理サーバ１０Ａ（サーバ１０Ａ）の構成を示す機能ブロック図である。サーバ１０Ａは、図示しないＨＤＤ等の記憶部及びＣＰＵ等から構成される制御部などを有し、制御部が記憶部に記憶されているビデオゲーム処理プログラムを実行することでビデオゲームの進行を制御する。また、サーバ１０Ａは、同プログラムを実行することで、ユーザ情報管理部３１、受付部３２、算出部３３、環境決定部３４及び分布情報送信部３５を少なくとも備える。なお、サーバ１０Ａは、上述した制御部や通信部等のビデオゲームを行うための一般的な構成を備えるが、ここでの説明は省略する。なお、ビデオゲーム処理プログラムには、テクスチャデータなどのゲームデータも含まれる。
【００２１】
ユーザ情報管理部３１は、図３に示すようなユーザ情報をユーザ毎にデータベース１２で管理する。ユーザ情報は、ユーザのビデオゲームに関連する情報であり、ユーザＩＤに関連付けてプレイヤキャラクタ、所有アイテム、プレイ時間などの情報が登録されている。ユーザＩＤは、各ユーザに付与される固有の識別情報である。サーバ１０Ａは、このユーザ情報に基づいて各ユーザのビデオゲームの進行を制御する。
【００２２】
プレイヤキャラクタの情報は、プレイヤキャラクタに関する各種情報が含まれる。例えば、レベル、ヒットポイント、攻撃力、防御力などの各種パラメータがある。所有アイテムの情報は、ユーザがゲーム内で使用可能なアイテムの情報が含まれる。所有アイテムの情報には、例えば、アイテム種類を特定するアイテムＩＤが登録されている。アイテムＩＤは、アイテムに付与された固有の識別情報である。プレイ時間は、ビデオゲームをプレイした累計時間である。ユーザ情報管理部３１は、例えば、ゲームが進行する毎にユーザ情報を更新する。
【００２３】
受付部３２は、ユーザからのレイドバトルの参加を受け付ける。ユーザは、自身のユーザ端末２０，２０１〜２０Ｎで参加要求の操作を行う。ユーザ端末２０，２０１〜２０Ｎは、参加要求の操作に基づいてサーバ１０Ａ（受付部３２）にレイドバトルの参加要求を送信する。
【００２４】
算出部３３は、レイドバトルにおける参加ユーザのレベル平均値を含む参加ユーザ情報を算出する。上述したように、参加ユーザに対応するデータベース１２のユーザ情報からレベルの情報を取得してレベル平均値を算出する。
【００２５】
環境決定部３４は、レベル平均値に基づいてレイドバトルのレイドボスの強さ（環境）を決定する。上述したように、レベル平均値に基づいてレイドボスのヒットポイントの最大値を決定する。例えば、レイドボスのヒットポイントの基準値（標準値）が設定されている場合、レベル平均値に基づいて基準値を変更する。より具体的には、レベルの範囲が１〜８０におけるレベル平均値が３０未満の場合、基準値を５０％減少させた値をヒットポイントの最大値として決定する。一方、レベル平均値が３０以上の場合には、基準値をヒットポイントの最大値として決定する。なお、レイドボスのヒットポイントなどの各種パラメータはゲームデータに含めておけばよい。
【００２６】
なお、レイドボスのヒットポイントの最大値は、上述の算出方法に限定されるものではない。レベル平均値に基づいて決定すればいずれの方法を採用してもよい。
【００２７】
分布情報送信部３５は、成長度（レベル）に関する参加ユーザの分布を表示させるための分布情報を生成し、参加ユーザのそれぞれのユーザ端末に送信する。分布情報を受信したユーザ端末は、例えば、図４に示すような分布画像をユーザ端末の表示装置に表示させる。図４は、レイドバトルの参加ユーザのレベル平均値の分布画像の一例である。分布画像には、レベル平均値と、レベル別の参加ユーザの人数が含まれる。レベル別の参加ユーザの人数において、ハッチング部分のレベルがユーザのレベルであることを示している。例えば、図４に示された分布画像では、ユーザのレベルが１８であることを把握できる。
【００２８】
したがって、参加ユーザは、自身が参加したレイドバトルにおいて、参加ユーザ全体の中で自身がどれくらいの位置にいるのかを分布画像から把握することができる。例えば、参加ユーザは、自身のレベルが参加ユーザの中で上位であると把握した場合、レイドボスを倒すべく、レベルの低い他の参加ユーザよりも活躍しようとするモチベーションが生じる。なお、分布画像において、レベル平均値、ハッチングの表示はなくてもよい。
【００２９】
複数のユーザ端末２０，２０１〜２０Ｎは、それぞれ、ビデオゲームを行うユーザによって管理され、例えば、据置型ゲーム装置、パーソナルコンピュータ、携帯電話端末やＰＤＡ（Personal Digital Assistants）、携帯型ゲーム装置などのネットワーク配信型のゲームを行うことが可能な通信端末によって構成される。
【００３０】
複数のユーザ端末２０，２０１〜２０Ｎは、それぞれ、通信ネットワーク３０に接続され、ビデオゲーム処理サーバ１０との通信を行うことによりビデオゲームを実行するためのハードウェア（例えば、プレイヤキャラクタを操作するための操作装置、ゲーム画像を表示する表示装置や音声出力装置など）及びソフトウェア（プログラム）を備える。
【００３１】
次に、この実施形態のビデオゲーム処理システム１００（システム１００）の動作について説明する。
【００３２】
図５は、システム１００が実行するバトル処理の例を示すフローチャートである。本例におけるバトル処理では、レイドバトルを実行する処理が行われる。以下、サーバ１０Ａとユーザ端末２０，２０１（端末２０，２０１）とがバトル処理を実行する場合を例にして説明する。なお、図５では、端末２０，２０１についてのみ説明するが、他のユーザ端末２０２〜２０Ｎも同様である。
【００３３】
本例のバトル処理は、例えばサーバ１０Ａが、レイドバトルの参加受付を開始したことに応じて開始される。
【００３４】
バトル処理において、サーバ１０Ａは、受付期間が終了する（ステップＳ１２：ＹＥＳ）まで、端末２０，２０１からの参加要求を待つ。そして、サーバ１０Ａは、ユーザ（端末２０，２０１）から参加要求を受信した場合（ステップＳ１０：ＹＥＳ）、受付処理を実行する（ステップＳ１１）。受付処理では、例えば、参加要求のあったユーザのユーザＩＤなどを参加ユーザとして記憶部に記憶する。
【００３５】
受付期間が経過した場合（ステップＳ１２：ＹＥＳ）、サーバ１０Ａは、１以上の参加ユーザがいるか否かを判断する（ステップＳ１３）。参加ユーザがいないと判断した場合（ステップＳ１３：ＮＯ）、サーバ１０Ａは、バトル処理を終了する。一方、１以上の参加ユーザがいると判断した場合（ステップＳ１３：ＹＥＳ）、サーバ１０Ａは、レイドボスの環境決定を行う（ステップＳ１４）。本実施形態の例では、上述したように、参加ユーザのレベルをデータベース１２から取得してレベル平均値を算出し、レイドボスのヒットポイントの最大値を決定する。
【００３６】
次に、サーバ１０Ａは、分布情報を生成して参加ユーザのそれぞれの端末２０，２０１に送信する（ステップＳ１５）。例えば、サーバ１０Ａは、レベル平均値と参加ユーザのレベルの情報（分布情報）とをユーザ端末２０，２０１に送信する。そして、端末２０，２０１は、受信した分布情報等に基づいて、図４に示すような分布画像（ゲーム画像）を表示装置に表示させる（ステップＳ２０）。
【００３７】
その後、サーバ１０Ａは、バトル進行処理を実行する（ステップＳ１６）。バトル進行処理では、ユーザ（端末２０，２０１）から受信した操作情報などから、プレイヤキャラクタとレイドボスとの戦闘を進行する処理が行われる。また、レイドバトルの進行状況を示すバトル情報等が参加ユーザの端末２０，２０１に送信される。端末２０，２０１は、受信したバトル情報等に基づいて表示装置にバトル画像（ゲーム画像）等を表示する（ステップ２１）
バトル進行処理は、レイドバトルが終了するまで行われる。例えば、レイドボスのヒットポイントが最大値から減少して０（ユーザ側の勝利）となった場合に終了する。なお、制限時間が到来した場合には、例えばレイドボスを倒せなかった（ユーザ側の敗北）として終了する。
【００３８】
その後、サーバ１０Ａは、報酬付与処理を実行する（ステップＳ１７）。報酬付与処理では、レイドバトルの結果に応じた報酬を参加ユーザのそれぞれに付与する処理が行われる。例えば、レイドボスを倒した場合には、参加ユーザのそれぞれにアイテムを付与する。具体的には、報酬のアイテム(アイテムＩＤ)を、参加ユーザのユーザ情報の所有アイテムに追加設定する。なお、レイドボスを倒せなかった場合には、例えば、参加ユーザに報酬は付与されない。あるいは、レイドボスを倒した場合よりも、価値の低いアイテムを付与するようにしてもよい。
【００３９】
また、報酬処理では、報酬の付与状況を示す報酬情報等が参加ユーザの端末２０，２０１に送信される。端末２０，２０１は、受信した報酬情報等に基づいて表示装置に報酬画像等を表示する（ステップＳ２２）。
【００４０】
以上のように、第１の実施形態の一側面として、ビデオゲーム処理サーバ１０Ａが、ユーザ情報管理部３１、受付部３２、算出部３３、環境決定部３４及び分布情報送信部を備える構成としているので、対戦ゲームの参加ユーザの成長度（レベル）の平均値に応じて、対戦ゲームの環境が決定される。したがって、成長度の低い初心者などのユーザであっても、他ユーザを気にせずに対戦ゲームに参加し易い。
【００４１】
なお、第１の実施形態の例では、レイドバトルの開始（ステップＳ１６の処理）前に環境（レイドボスのヒットポイントの最大値）が決定されるが、決定されるタイミングは、特に限定されない。例えば、レイドバトルの実行中にもユーザが参加可能である場合は、参加ユーザが変化する毎にレベル平均値を算出して環境を決定してもよい。この場合、レイドボスのヒットポイントの最大値ではなく、例えば、レイドボスの攻撃力や防御力の値を変更するようにすればよい。
【００４２】
［第２の実施形態］
図６は、ビデオゲーム処理サーバ１０の例であるビデオゲーム処理サーバ１０Ｂ（サーバ１０Ｂ）の構成を示すブロック図である。本例において、サーバ１０Ｂは、ユーザ情報管理部３１、受付部３２、算出部３３Ｂ、環境決定部３４Ｂ及び分布情報送信部３５を少なくとも備える。
【００４３】
ユーザ情報管理部３１は、ユーザ情報をユーザ毎にデータベース１２で管理する。受付部３２は、ユーザからレイドバトルの参加を受け付ける。
【００４４】
算出部３３Ｂは、レイドバトルの参加ユーザにおける初心者の割合を含む参加ユーザ情報を算出する。例えば、算出部３３Ｂは、成長度（レベル）が所定範囲（例えば、レベル１０以下）であり、且つ、プレイ時間が所定時間以上（例えば、１０時間以上）のユーザを初心者として判断する。すなわち、本実施形態の例では、レベルが低くてプレイ時間が長いユーザほど、うまくゲームを進められない初心者と判断される。ユーザの成長度及びプレイ時間は、データベース１２の各ユーザ情報を参照すればよい。
【００４５】
なお、初心者の判断は、上記例には限定されない。例えば、レベルが所定値以下のユーザを初心者と判断してもよい。あるいは、プレイ時間が所定時間以下のユーザを初心者と判断してもよい。
【００４６】
環境決定部３４Ｂは、初心者の割合に基づいて、レイドバトルで参加ユーザに付与される報酬の内容を決定する。本実施形態の例では、レイドボスを倒すことで付与されるアイテムなどの報酬の内容が、初心者の割合に基づいて決定される。
【００４７】
例えば、環境決定部３４Ｂは、初心者の割合に基づいて報酬係数を決定し、図７に示すような報酬候補リスト９０から報酬内容を決定する。報酬候補リスト９０には、報酬係数に報酬内容が対応付けて登録されている。報酬内容には、例えば、報酬抽選テーブルを特定する報酬ＩＤが登録されている。報酬抽選テーブルには、付与される報酬の候補となる複数のアイテム情報が登録されている。本実施形態において付与される報酬は、報酬抽選テーブルを用いた抽選で当選したアイテムとなる。本実施形態の例では、３種類の報酬抽選テーブルＡ〜Ｃが報酬係数に対応付けられている。各報酬抽選テーブルＡ〜Ｃは、候補となるアイテムの種類の少なくとも一部が異なっている。
【００４８】
本実施形態の例では、｛報酬係数１：初心者の割合２０％未満｝、｛報酬係数２：初心者の割合２０％以上７０％未満｝。｛報酬係数３：初心者の割合７０％以上｝とし、初心者の割合が高くなるほど、価値の高いアイテムが含まれる報酬抽選テーブルが使用されるように設定されている。報酬候補リスト９０、報酬抽選テーブルＡ〜Ｃは、例えばゲームデータに含めておけばよい。
【００４９】
なお、本実施形態の例では、１の報酬候補リスト９０が用いられているが、複数の報酬候補リストを用いてもよい。例えば、対戦するレイドボスの種類ごとに、異なる報酬候補リストを用いる。なお、報酬の内容には、報酬の種類のほか、数も含まれる。例えば、報酬抽選テーブルに代えて、抽選実行回数を報酬候補リストに登録する。この場合、使用される報酬抽選テーブルは固定であるが、初心者の割合が高くなるほど抽選実行回数が多くなるように設定することで、初心者の割合が高くなるほど獲得できる報酬のアイテム数が多くなる。
【００５０】
分布情報送信部３５は、成長度（レベル）に関する参加ユーザの分布を表示させるための分布情報を生成し、参加ユーザのそれぞれのユーザ端末に送信する。
【００５１】
図８は、システム１００が実行するバトル処理の例を示すフローチャートである。本例におけるバトル処理では、レイドバトルを実行する処理が行われる。以下、サーバ１０Ｂとユーザ端末２０，２０１（端末２０，２０１）とがバトル処理を実行する場合を例にして説明する。なお、図８では、端末２０，２０１についてのみ説明するが、他のユーザ端末２０２〜２０Ｎも同様である。
【００５２】
本例のバトル処理は、例えばサーバ１０Ｂが、レイドバトルの参加受付を開始したことに応じて開始される。
【００５３】
バトル処理において、サーバ１０Ｂは、受付期間が終了する（ステップＳ１２：ＹＥＳ）まで、端末２０，２０１からの参加要求を待つ。そして、サーバ１０Ｂは、ユーザ（端末２０，２０１）から参加要求を受信した場合（ステップＳ１０：ＹＥＳ）、受付処理を実行する（ステップＳ１１）。
【００５４】
受付期間が経過した場合（ステップＳ１２：ＹＥＳ）、サーバ１０Ｂは、１以上の参加ユーザがいるか否かを判断する（ステップＳ１３）。参加ユーザがいないと判断した場合（ステップＳ１３：ＮＯ）、サーバ１０Ｂは、バトル処理を終了する。一方、１以上の参加ユーザがいると判断した場合（ステップＳ１３：ＹＥＳ）、サーバ１０Ｂは、レイドボスの環境決定を行う（ステップＳ１４−Ｂ）。本実施形態の例では、上述したように、参加ユーザのレベル及びプレイ時間をデータベース１２から取得し、初心者の割合を算出する。そして、初心者の割合に基づいて報酬係数を決定して報酬抽選テーブルを決定する。
【００５５】
次に、サーバ１０Ｂは、分布情報を生成して参加ユーザ２０，２０１のそれぞれのユーザ端末に送信する（ステップＳ１５）。
【００５６】
その後、サーバ１０Ｂは、バトル進行処理を実行する（ステップＳ１６−Ｂ）。本実施形態の例のバトル進行処理では、レイドボスのヒットポイントの最大値は、参加ユーザに関係なく基準値が設定される。
【００５７】
その後、サーバ１０Ｂは、報酬付与処理を実行する（ステップＳ１７−Ｂ）。本実施形態の例の報酬処理では、レイドボスを倒した場合、ステップＳ１４−Ｂの処理で決定された報酬抽選テーブルを用いて所定回数の抽選が行われる。そして、当選したアイテムが参加ユーザのそれぞれに付与される。
【００５８】
以上のように、第２の実施形態の一側面として、ビデオゲーム処理サーバ１０Ｂが、ユーザ情報管理部３１、受付部３２、算出部３３−Ｂ、環境決定部３４−Ｂ及び分布情報送信部３５を備える構成としているので、対戦ゲームの参加ユーザの初心者の割合に応じて、対戦ゲームの環境が決定される。したがって、初心者などのユーザであっても、他ユーザを気にせずに対戦ゲームに参加し易い。
【００５９】
なお、第２の実施形態の例では、レイドバトル終了後に付与される報酬の内容を決定していたが、レイドバトル中に参加ユーザに付与される報酬の内容を決定するようにしてもい。例えば、レイドバトル中、レイドボスへの攻撃によって発生（ドロップ）するアイテムも報酬に含まれ、このドロップされる報酬の内容を決定してもよい。
【００６０】
また、第２の実施形態の例では、レイドバトルの開始（ステップＳ１６−Ｂの処理）前に環境（報酬の内容）が決定されるが、決定されるタイミングは、特に限定されない。例えば、ステップＳ１７−Ｂの報酬付与処理時に、初心者の割合を算出して報酬の内容を決定してもよい。
【００６１】
なお、各実施形態の例の対戦ゲームは、プレイヤキャラクタを用いた対戦に限定されず、例えば仮想のカードを用いて敵と戦うゲーム等も含まれる。また、各実施形態の例におけるユーザのプレイヤキャラクタは、複数であってもよい。例えば、複数のプレイヤキャラクタで構成されるパーティを用いて単一のユーザが対戦ゲームに参加する構成がある。
【００６２】
また、各実施形態の例において決定される対戦ゲームの環境は、ゲームフィールドの種類及び大きさ、敵の強さ、報酬の内容、対戦ゲームの制限時間など、いずれを対象としてもよく、複数の環境について決定してもよい。
【００６３】
さらに、各実施形態の例では、分布情報を生成して参加ユーザのユーザ端末に送信しているが、送信しなくてもよい。
【産業上の利用可能性】
【００６４】
本発明の実施形態の一つによれば、成長度の低い初心者などのユーザであっても、他ユーザを気にせずに対戦ゲームに参加し易くするのに有用である。
【符号の説明】
【００６５】
１０    ビデオゲーム処理サーバ
１２    データベース
２０，２０１〜２０Ｎ    ユーザ端末
３０    通信ネットワーク
３１    ユーザ情報管理部
３２    受付部
３３    算出部
３４    環境決定部
３５    分布情報送信部
１００    ビデオゲーム処理システム
【図１】
2018038555.tif 000003
【図２】
2018038555.tif 000004
【図３】
2018038555.tif 000005
【図４】
2018038555.tif 000006
【図５】
2018038555.tif 000007
【図６】
2018038555.tif 000008
【図７】
2018038555.tif 000009
【図８】
2018038555.tif 000010