JP5796146B1 - プログラム、情報処理装置、及びゲームシステムの制御方法 - Google Patents

Abstract

【課題】戦略性の発揮が継続的に必要な共通の目的を提供して、ユーザのグループ内での交流を盛んにすることができるプログラム、情報処理装置、及びゲームシステムの制御方法を提供する。【解決手段】プログラムであって、通信端末２に対してゲームを提供するコンピュータ（ゲームサーバ１）に、（ａ）通信端末のユーザのプレイヤキャラクタに、プレイヤキャラクタを含んで構成されるグループで共有される共有キャラクタを付与するステップと、（ｂ）グループを構成するプレイヤキャラクタの行動に応じて、共有キャラクタの有する属性の少なくとも一つを変化させるステップと、を実行させる。【選択図】図１

Description

本発明は、プログラム、情報処理装置、及びゲームシステムの制御方法に関する。

従来から、コンピュータ等の情報処理装置を用いるビデオゲームにおいて、ユーザがゲーム内のプレイヤキャラクタを操作するものが知られている。プレイヤキャラクタは、ゲーム内でユーザの操作に従って行動する仮想ユーザである。例えば、特許文献１では、プレイヤキャラクタを操作して相手との対戦を行う対戦ゲームについて記載されている。

特開２００７−０７５６１２号公報

ここで、複数のユーザがクライアント端末を用いて参加するオンラインゲームにおいて、複数のユーザが操作する複数のプレイヤキャラクタでギルドとよばれるグループ（チーム）を構成し、共同で対戦または任務の遂行等を行うものがある。ギルドを構成するプレイヤキャラクタ（以下、ギルドメンバーともいう）のユーザにとっては、ギルド内での交流の活発さは、ゲーム全体への興趣を向上させる重要なファクターとなり得る。

しかし、ギルドが例えば対戦の勝利といった特定の目的のためのチームである場合、対戦経験の蓄積とともに戦略性を発揮する必要性が低下し、ギルドメンバー同士の交流が低下する傾向があった。

このような問題点に鑑みてなされた本発明の目的は、戦略性の発揮が継続的に必要な共通の目的を提供して、ユーザのギルド内での交流を盛んにすることができるプログラム、情報処理装置、及びゲームシステムの制御方法を提供することにある。

上記課題を解決するために、本発明に係るプログラムは、共有キャラクタデータを含む記憶部を備え、通信端末に対してゲームを提供するコンピュータに、前記通信端末のユーザのプレイヤキャラクタを含んで構成されるグループと、前記グループで共有される共有キャラクタとを、前記共有キャラクタデータで関連付けて、前記記憶部に記憶させるステップと、前記グループを構成するプレイヤキャラクタの行動に応じて、前記共有キャラクタの有する属性の少なくとも一つを変化させて、変化した属性について前記共有キャラクタデータを更新する第１更新ステップと、前記共有キャラクタの属性を変化させたことへの貢献度を、前記グループを構成するプレイヤキャラクタごとに計算するステップと、前記貢献度が最も高いプレイヤキャラクタの種類に応じて、前記共有キャラクタの属性の変化の大きさおよび方向の少なくとも一方について決定を行い、前記決定が反映されるように前記共有キャラクタデータを更新する第２更新ステップと、を実行させることを特徴とする。

また、本発明に係るプログラムにおいて、前記第２更新ステップは、前記共有キャラクタの所定のレベルにおける前記貢献度を用いて前記決定を行うことが好ましい。

また、本発明に係るプログラムは、前記ゲームは対戦ゲームであって、前記コンピュータに、前記プレイヤキャラクタの対戦におけるステータス、および前記プレイヤキャラクタが対戦において用いる前記共有キャラクタのステータスの少なくとも一方を、前記グループを構成するプレイヤキャラクタの貢献度に応じて変化させるステップ、を更に実行させることが好ましい。

また、本発明に係るプログラムは、前記コンピュータに、所定の条件が満たされる場合に、前記通信端末のユーザに報酬を付与するステップ、を更に実行させて、前記第１更新ステップにおいて、前記通信端末のユーザが前記報酬を用いることで、前記共有キャラクタの属性が変化することが好ましい。

また、上記課題を解決するために、本発明に係る情報処理装置は、通信端末に対してゲームを提供する情報処理装置であって、共有キャラクタデータを含む記憶部と、前記通信端末のユーザのプレイヤキャラクタを含んで構成されるグループと、前記グループで共有される共有キャラクタとを、前記共有キャラクタデータで関連付けて、前記記憶部に記憶させる、第２の管理部と、前記共有キャラクタの属性を変化させたことへの貢献度を、前記グループを構成するプレイヤキャラクタごとに計算する、第３の管理部と、を備え、前記第２の管理部は、前記グループを構成するプレイヤキャラクタの行動に応じて、前記共有キャラクタの有する属性の少なくとも一つを変化させて、変化した属性について前記共有キャラクタデータを更新し、前記貢献度が最も高いプレイヤキャラクタの種類に応じて、前記共有キャラクタの属性の変化の大きさおよび方向の少なくとも一方について決定を行い、前記決定が反映されるように前記共有キャラクタデータを更新することを特徴とする。

また、上記課題を解決するために、本発明に係るゲームシステムの制御方法は、通信端末と、共有キャラクタデータを含む記憶部を備え、前記通信端末に対してゲームを提供する情報処理装置と、を含むゲームシステムの制御方法であって、前記通信端末のユーザのプレイヤキャラクタを含んで構成されるグループと、前記グループで共有される共有キャラクタとを、前記共有キャラクタデータで関連付けて、前記記憶部に記憶するステップと、前記グループを構成するプレイヤキャラクタの行動に応じて、前記共有キャラクタの有する属性の少なくとも一つを変化させて、変化した属性について前記共有キャラクタデータを更新するステップと、前記共有キャラクタの属性を変化させたことへの貢献度を、前記グループを構成するプレイヤキャラクタごとに計算するステップと、前記貢献度が最も高いプレイヤキャラクタの種類に応じて、前記共有キャラクタの属性の変化の大きさおよび方向の少なくとも一方について決定を行い、前記決定が反映されるように前記共有キャラクタデータを更新するステップと、を含むことを特徴とする。

本発明におけるプログラム、情報処理装置、及びゲームシステムの制御方法によれば、戦略性の発揮が継続的に必要な共通の目的を提供して、ユーザのギルド内での交流を盛んにすることができる。

本発明の一実施形態に係るゲームシステムのブロック図である。 図１のユーザデータの例を示す図である。 図１の共有キャラクタデータの例を示す図である。 図１のギルドデータの例を示す図である。 図１の貢献度データの例を示す図である。 本実施形態に係るゲームシステムの情報処理装置が配信するゲームの対戦画面の例を示す図である。 本実施形態に係るゲームシステムの情報処理装置の動作を示すフローチャートである。

（システム全体構成）
以下、本発明の実施形態について説明する。図１は、本発明の一実施形態に係るゲームシステムのブロック図である。ゲームシステムは、情報処理装置と、複数の通信端末２と、を備える。本実施形態において、情報処理装置はゲームサーバ１である。また、図１では簡便のため、通信端末２は１つのみ図示している。

ゲームサーバ１は、通信端末２に対してゲームを配信する。このゲームにおいて、通信端末２のユーザのプレイヤキャラクタはグループ（チーム）を構成できる。本実施形態において、ゲームサーバ１が配信するゲームは対戦ゲームであって、ゲーム内で構成されるグループ（チーム）をギルドと呼ぶ。本実施形態において、通信端末２のユーザは、プレイヤキャラクタの行動を決定し、対戦相手（例えば、敵キャラクタ）との対戦を行う。対戦は、例えばプレイヤキャラクタが敵キャラクタに遭遇する等、ゲーム中において所定の対戦イベントが発生した場合に行われる。また、本実施形態において、対戦は味方のプレイヤキャラクタの属するギルドと、敵キャラクタの属するギルドとの間（ＧＶＧ：Guildversus Guild）で行われるが、ギルドの構成員の人数は複数に限らず１人であってもよい。また、ギルドは１人のユーザが結成を他のユーザに呼びかけて結成されるものであってもよいし、ユーザが自動的にギルドに配属されることで結成されるものであってもよい。なお、ゲームサーバ１が配信するゲームの種類は、対戦ゲームに限定されるものではない。

ゲームサーバ１は、サーバ通信部１０と、記憶部１１と、サーバ制御部１５と、第１の管理部３１と、第２の管理部３２と、第３の管理部３３と、を備える。

サーバ通信部１０は通信端末２と通信する。本実施形態において、サーバ通信部１０は、通信端末２と無線で通信するが、有線によって通信してもよい。また、サーバ通信部１０は、無線通信と有線通信とを併用可能または選択可能であってもよい。

記憶部１１は、ユーザデータ１１０、共有キャラクタデータ１１１、ギルドデータ１１２、および貢献度データ１１３（以下、まとめて管理データともいう）を記憶する。本実施形態において、それぞれのデータはテーブル形式で記憶部１１に記憶されるが、詳細については後述する。

サーバ制御部１５は、ゲームサーバ１の各種動作及びゲーム全体の進行を制御する。サーバ制御部１５は、ユーザが対戦する対戦相手を決定し、サーバ通信部１０を介して、種々のゲーム画面を表示させる指示を通信端末２に送信する。また、サーバ制御部１５は、ゲームの適切な進行のため、第１の管理部３１、第２の管理部３２、および第３の管理部３３を制御して、ユーザデータ１１０、共有キャラクタデータ１１１、ギルドデータ１１２、および貢献度データ１１３の管理（例えば値の更新等）を実行させる。

通信端末２は、端末通信部２０と、表示部２１と、操作部２２と、端末制御部２４と、を備える。

端末通信部２０はゲームサーバ１と通信する。本実施形態において、端末通信部２０は、ゲームサーバ１と無線で通信するが、有線によって通信してもよい。また、端末通信部２０は、無線通信と有線通信とを併用可能または選択可能であってもよい。

表示部２１は、ゲームサーバ１から提供されるゲームの進行に応じて、ゲーム画面の表示を行う。例えば、表示部２１は、味方および敵のギルドのメンバーと、各メンバーのステータス等が表示された対戦画面を表示してもよい。また、例えば、表示部２１は、味方のギルドのメンバーが、船で次の目的地に向かって移動している画面を表示してもよい。表示部２１には、液晶ディスプレイや有機ＥＬディスプレイ等、任意の表示デバイスを採用可能である。

操作部２２は、ゲームに対して行われるユーザ操作を受け付ける。そして、操作部２２は、受け付けたユーザ操作に応じた入力信号を端末制御部２４に渡す。操作部２２には、ボタンやタッチパネル等、任意の入力インターフェースを採用可能である。以下において、操作部２２はタッチパネルであるとして説明する。

端末制御部２４は、通信端末２の各種動作を制御する。また、端末制御部２４は、表示部２１に表示される各種画面において受け付けたユーザ操作に応じた入力信号を操作部２２から取得すると、端末通信部２０を介して当該入力信号をゲームサーバ１に送信する。

（共有キャラクタ）
本実施形態に係るゲームシステムのゲームサーバ１は、味方のギルドと敵のギルドとの対戦を行うゲームを提供するが、このゲームにおいて味方のギルドは対戦におけるグループ（チーム）だけではなく、共有キャラクタを成長、変化させるためのグループ（チーム）となる。共有キャラクタは例えば生き物（ペット等）、移動体（乗り物等）、建物等であるが、成長、変化可能な共有物であれば特に限定されるものではない。

共有キャラクタは、付与条件が満たされる場合に、通信端末のユーザのプレイヤキャラクタに付与される。例えば、共有キャラクタは、ゲームをスタートするときにプレイヤキャラクタに自動的に付与されてもよい。つまり、付与条件は通信端末２のユーザがゲームに参加することであってもよい。また、別の例として、付与条件はプレイヤキャラクタがゲーム内で特定の地点に到達すること、または特定の対戦に勝利すること等であってもよい。

このとき、付与される共有キャラクタは、ある特定のプレイヤキャラクタに所有され、その属性は初期状態である。例えば共有キャラクタがペット等の生き物であれば孵化する前の卵として付与されてもよい。また、例えば共有キャラクタが移動体であれば、エンジンや防護装備のグレードが最も低い状態で付与されてもよい。また、例えば共有キャラクタが建物であれば、外壁が単一色で装飾性のない状態で付与されてもよい。ここで属性とは、共有キャラクタが備える成長要素を含む性質のことである。属性としては、例えば対戦能力（レベル、攻撃力、防御力等）、外観、動作および性能等が挙げられるが、本実施形態においては、共有キャラクタの区分に応じて属性が定められる。例えば共有キャラクタがペットであれば、その属性は対戦能力および外観の少なくとも一つである。また、例えば共有キャラクタが建物であれば、その属性は外観である。ゲームサーバ１は、属性の変化（成長）を、パラメータ（例えばレベル）の数値と対応させて管理する。

共有キャラクタは、それを所有するプレイヤキャラクタが属するギルド、つまり、そのプレイヤキャラクタを含んで構成されるギルドで共有され得る。ギルドで共有された共有キャラクタは、後述するように所有者であるプレイヤキャラクタの行動のみならず、ギルドを構成する他のプレイヤキャラクタの行動によっても属性が変化する。共有キャラクタの属性の変化の大きさ、方向等が、所有者であるプレイヤキャラクタの行動のみで決まらないため、ギルドとして戦略的に共有キャラクタを育てる（属性を変化させる）必要がある。言い換えると、共有キャラクタを希望通りに育てるという共通の目的を達成するためには、ギルド内で盛んに交流を行い、対戦場面だけでなく継続的に戦略性を発揮する必要が生じる。

また、ギルドで共有される共有キャラクタの数に上限が設けられていてもよい。例えば、ギルドを５人以上のプレイヤキャラクタで構成し、各プレイヤキャラクタが１つ以上の共有キャラクタを有しているとする。このとき、ギルドで共有可能な共有キャラクタの上限が４つであれば、ゲームの進行上、有利な共有キャラクタを選択するために、ギルド内で戦略の検討が行われる可能性が高くなる。なお、以下においては、ギルドで共有される共有キャラクタの数に特に上限はなく、ギルドメンバーが所有する共有キャラクタは自動的にギルドで共有されるものとして説明する。

（管理部について）
本実施形態に係るゲームシステムのゲームサーバ１は、ギルドで共有される共有キャラクタに関連して、第１の管理部３１、第２の管理部３２、および第３の管理部３３を用いて、記憶部１１に記憶されたユーザデータ１１０、共有キャラクタデータ１１１、ギルドデータ１１２、および貢献度データ１１３を管理する。

第１の管理部３１は、ユーザおよびそのプレイヤキャラクタに関する情報を主に管理するブロックであって、後述するようにユーザデータ１１０、ギルドデータ１１２等を必要に応じて更新する。

第２の管理部３２は、共有キャラクタのアップグレード（成長、変化）に関する情報を主に管理するブロックであって、後述するように共有キャラクタデータ１１１等を必要に応じて更新する。

第３の管理部３３は、共有キャラクタの属性を変化させたことへの貢献度を主に管理するブロックであって、後述するように貢献度データ１１３等を必要に応じて更新する。本実施形態において、貢献度とは、あるプレイヤキャラクタが共有キャラクタのアップグレードにどの程度貢献したかを相対的に示す数値である。例えば、ギルドのメンバーのうちで、あるプレイヤキャラクタのみが、ペットである共有キャラクタにえさ（例えば、食料アイテム）を与えて育てたとする。このとき、共有キャラクタの成長に関して、えさを与えたプレイヤキャラクタの貢献度は１００％であって、他のプレイヤキャラクタの貢献度は０％である。

ここで、第１の管理部３１、第２の管理部３２、および第３の管理部３３の全てまたは一部を併合して１つのブロックとしてもよい。逆に、第１の管理部３１、第２の管理部３２、および第３の管理部３３の全てまたは一部について、更にブロックを分けてもよい。また、ゲームサーバ１は、記憶部１１に記憶されるプログラムに従って動作するコンピュータであって、第１の管理部３１、第２の管理部３２、および第３の管理部３３の全てまたは一部がソフトウェアで実現されてもよい。例えば、記憶部１１に記憶されるプログラムが、コンピュータを第１の管理部３１、第２の管理部３２、および第３の管理部３３として機能させてもよい。

（ユーザデータ）
図２は、管理データのうちのユーザデータ１１０の例を示す図である。ユーザデータ１１０では、通信端末のユーザを一意に識別可能なＩＤ（例えばＵ００１）で区別した上で、ＩＤと対応づけて、“レベル”、“経験値”、“所持金”、“共有キャラクタ”、“所持アイテム”、“ジョブ”、“ステータス”のパラメータについてテーブル管理している。また、パラメータは図２に示されるものに限られず、例えばプレイ時間、武器や防具といった装備の情報等を更に含んでもよいし、逆に一部のパラメータが省略されていてもよい。ユーザデータ１１０は、主として第１の管理部３１によって管理される。

ユーザのＩＤは、本実施形態においては“Ｕ”の文字に３桁の数字を組み合わせているが、これに限られるものではない。例えば、ユーザを一意に識別可能であるならば、ユーザが任意に設定したプレイヤキャラクタ名としてもよい。なお、本実施形態においては１人のユーザは１つのプレイヤキャラクタを操作するとして説明する。“レベル”は、ゲーム内におけるプレイヤキャラクタの成長度を示すパラメータであり、レベルの数値が高いほど成長度が高いことを示す。“経験値”は、レベルの上昇に寄与するパラメータであり、ゲームの進行や対戦等に応じて加算される。本実施形態において、経験値が１００％に達すると、レベルが上昇する。このとき、新しいレベルに設定されると共に経験値は０％にリセットされる。“所持金”は、ユーザが所持するゲーム内通貨を示すパラメータであり、ゲームの進行や対戦等に応じて加算される。ゲーム内通貨は、本発明の報酬となり得るものであり、後述するアイテムの購入に用いることができる。なお、報酬とは、それを所有または使用することによりゲームを進める上で有用な効果を生じさせるものをいう。

“共有キャラクタ”は、前記のようにプレイヤキャラクタによって所有されるが、そのプレイヤキャラクタが属するギルドで共有される。共有キャラクタは、本実施形態においては“Ｃ”の文字に３桁の数字を組み合わせたＩＤで区別される。例えば、ＩＤがＵ００３であるユーザは、ＩＤがＣ００２である共有キャラクタを所有している。

“所持アイテム”は、ユーザが所持しているアイテムである。アイテムは本発明の報酬の一種であり、ユーザがギルドを構成するプレイヤキャラクタを操作することで、ギルドで共有している共有キャラクタに対してアイテムを用いて、その共有キャラクタの属性を変化させることができる。例えばＩＤがＵ００１であるユーザは、ＩＤがＣ００３である共有キャラクタ（後述するように区分はペット）のえさを所持しており、えさを与えることで共有キャラクタの有する属性（例えば対戦能力および外観）の少なくとも一つを変化させることができる。また、例えばＩＤがＵ００２であるユーザは、ＩＤがＣ００１である共有キャラクタ（後述するように区分は建物）の装飾Ａを所持しており、装飾Ａを施すことで共有キャラクタの有する属性（例えば外観）を変化させることができる。また、例えばＩＤがＵ００３であるユーザは、ＩＤがＣ００２である共有キャラクタ（後述するように区分は移動体）のエンジンＦを所持しており、エンジンＦに交換することで共有キャラクタの有する属性（例えば移動速度および移動可能範囲といった性能）の少なくとも一つを変化させることができる。

ここで、ユーザは、所定の条件が満たされる場合にアイテムを付与される。ここで、所定の条件は、例えば対戦に勝利することであってもよいし、アイテムを購入したことであってもよい。対戦で得られるアイテムは、例えば勝負をする両ギルドが賭けてもよいし（敗者負担）、勝利の賞品として提供されてもよい。特に、対戦によってアイテムを賭ける場合には、何を賭けるか等についてギルドとしての戦略が必要になり、ギルド内での交流の活発化が期待できる。また、対戦に勝利して得られたアイテムを誰の所有物とするかを話し合いで決めることができれば、さらにギルド内での交流の活発化が期待できる。なお、アイテムとは完成品にかぎらず、その一部（例えばかけら）であってもよい。

“ジョブ”は、プレイヤキャラクタのゲーム内での職業属性を表し、共有キャラクタの属性の変化の大きさ、方向等に影響を与えることがある。属性の変化の大きさ、方向が変化する条件は、共有キャラクタごとに定められている。例えばペットである共有キャラクタは、ジョブが戦士であるプレイヤキャラクタからえさをもらう場合にレベルがアップするスピードが速まってもよい。また、ペットである共有キャラクタは、ジョブが魔法使いであるプレイヤキャラクタからえさをもらう場合に魔法が使えるように変化してもよい。また、例えば移動体である共有キャラクタは、ジョブが職人であるプレイヤキャラクタがアイテムを使用した場合に移動速度が一層強化されてもよい。また、移動体である共有キャラクタは、ジョブが戦士であるプレイヤキャラクタがアイテムを使用した場合に防御力が一層高まってもよい。したがって、どのジョブのプレイヤキャラクタが共有キャラクタの属性を変化させるのに貢献する（以下、共有キャラクタを「育てる」とも表現する）かは、共有キャラクタの属性の将来的な変化に影響する。そのため、誰が共有キャラクタを育てるかについてギルドとしての戦略が必要になり、ギルド内での交流の活発化が期待できる。

“ステータス”は、共有キャラクタを対戦等で用いる場合における、プレイヤキャラクタのステータス（例えば攻撃力、防御力、ヒットポイント等）に対する影響を表す。図２の一つの例では、ＩＤがＵ００１であるユーザのプレイヤキャラクタのステータスは、ＩＤがＣ００３である共有キャラクタを使用（例えば対戦で召喚）した場合に、通常よりも５０％増加する。どのユーザが共有キャラクタを使用するかで対戦等での有利さが変化するため、ギルドとしての戦略が必要になり、ギルド内での交流の活発化が期待できる。

（共有キャラクタデータ）
図３は、管理データのうちの共有キャラクタデータ１１１の例を示す図である。共有キャラクタデータ１１１では、共有キャラクタを一意に識別可能なＩＤ（例えばＣ００１）で区別した上で、ＩＤと対応づけて、“区分”、“レベル”、“経験値”、“ギルド”、“属性の変化の大きさ”、“属性の変化の方向”、“ステータス”のパラメータについてテーブル管理している。また、パラメータは図３に示されるものに限られず、例えば対戦での召喚回数等の情報を更に含んでもよいし、逆に一部のパラメータが省略されていてもよい。共有キャラクタデータ１１１は、主として第２の管理部３２によって管理される。

共有キャラクタのＩＤは、本実施形態においては“Ｃ”の文字に３桁の数字を組み合わせているが、これに限られるものではない。“区分”は共有キャラクタのカテゴリーを示し、本実施形態では、生物であるペット、プレイヤキャラクタが移動の際に用いる乗り物である移動体、プレイヤキャラクタが住居または集合場所として用いる建物等がある。ペットには、例えば犬、猫等の愛玩動物だけでなく、プレイヤキャラクタが召喚することで対戦に参加する召喚獣が含まれてもよい。また、移動体は例えば船、車両、飛行機等が含まれてもよい。また、建物は例えばテント、ビル、城等が含まれてもよい。

“レベル”は、ゲーム内における共有キャラクタの属性の成長度を示すパラメータである。レベルの数値が高いほど成長度が高いことを示す。

“経験値”は、レベルの上昇に寄与するパラメータであり、アイテムの使用、対戦への参加等に応じて加算される。本実施形態において、経験値が１００％に達すると、レベルが上昇する。このとき、新しいレベルに設定されると共に経験値は０％にリセットされる。

“ギルド”は、共有キャラクタが共有されているギルドを示す。図３の一つの例では、ＩＤがＣ００２である共有キャラクタは、ＩＤがＧ００１であるギルドに共有されている。つまり、ＩＤがＣ００２である共有キャラクタは、その所有者であるプレイヤキャラクタが属するギルドで共有されている。ここで、例えばギルドで共有される共有キャラクタの数に上限が設けられている場合などで、共有キャラクタがギルドに共有されていない状態のときには空欄であってもよい。

“属性の変化の大きさ”は、共有キャラクタの属性がギルドを構成するプレイヤキャラクタの行動に応じて変化する際の変化量（成長の度合い）を定める。また、属性の変化の方向は、共有キャラクタの属性の変化の方向性（成長の方向性）を示す。“属性の変化の大きさ”および“属性の変化の方向”は、共有キャラクタの属性を変化させたことへの貢献度によって影響される。貢献度の具体例については後述する。

“属性の変化の大きさ”について具体的に説明する。図３の例では、ＩＤがＣ００２、Ｃ００３である共有キャラクタについて、属性の変化の大きさがそれぞれ１５０％、５０％になっている。そのため、ＩＤがＣ００２、Ｃ００３である共有キャラクタは、それぞれ通常の１．５倍、半分の速さで成長、すなわちレベルアップする。

“属性の変化の方向”について具体的に説明する。例えばＩＤがＣ００１である共有キャラクタは、建物であって、外観の装飾性が増加するタイプＡ（ｔｙｐｅＡ）と、防御力がアップするタイプＢという成長の方向性があり、貢献度に応じて一つの方向に定まる。また、例えばＩＤがＣ００２である共有キャラクタは、移動体であって、運搬できる人数等が増えるタイプＡと、敵に遭遇する確率が低くなるタイプＢと、移動スピードが速くなるタイプＣ（ｔｙｐｅＣ）といった成長の方向性があり、貢献度によって一つの方向に定まる。また、例えばＩＤがＣ００３である共有キャラクタは、ペットであって、打撃による攻撃力が強くなるタイプＡと、攻撃タイプの魔法が強くなるタイプＢと、回復タイプの魔法が強くなるタイプＣと、一部に特化することなくバランスよく強化されるタイプＤといった成長の方向性があり、貢献度によって一つの方向に定まる。図３の例では、ＩＤがＣ００１、Ｃ００２、Ｃ００３である共有キャラクタは、それぞれタイプＡ、タイプＣ、タイプＤの方向に成長する。ギルドは、例えば育てるプレイヤキャラクタを変更する（すなわち貢献度を変化させる）ことで、成長の度合いを向上させたり、共有キャラクタの属性の変化の方向を変えたりすることが可能である。つまり、今後の共有キャラクタの成長の方向性等に関してギルドとしての戦略が必要になり、ギルド内での交流の活発化が期待できる。

“ステータス”は、共有キャラクタを対戦等で用いる場合における、共有キャラクタのステータス（例えば攻撃力、防御力、ヒットポイント等）に対する影響を表す。共有キャラクタのステータスは、例えば貢献度の高いユーザのプレイヤキャラクタによって召喚された場合に、通常よりも高くなってもよい。図３の一つの例では、ＩＤがＣ００３である共有キャラクタのステータスは、ＩＤがＵ００１であるユーザのプレイヤキャラクタによって用いられる（例えば対戦中に召喚される）場合に通常よりも５０％増加する。どのユーザが共有キャラクタを召喚するかで対戦の有利さが変化するため、ギルドとしての戦略が必要になり、ギルド内での交流の活発化が期待できる。

（ギルドデータ）
図４は、管理データのうちのギルドデータ１１２の例を示す図である。ギルドデータ１１２では、ギルドを一意に識別可能なＩＤ（例えばＧ００１）で区別した上で、ＩＤと対応づけて、“ギルドメンバー”、“共有キャラクタ”のパラメータについてテーブル管理している。また、パラメータは図４に示されるものに限られず、例えば構成人数の履歴の情報等を更に含んでもよい。ギルドデータ１１２は、主として第１の管理部３１によって管理される。

ギルドのＩＤは、本実施形態においては“Ｇ”の文字に３桁の数字を組み合わせているが、これに限られるものではない。“ギルドメンバー”はギルドを構成するメンバー（構成員）をユーザのＩＤを用いて示すものである。また、“共有キャラクタ”はギルドで共有される共有キャラクタを共有キャラクタのＩＤを用いて示すものである。例えば、ＩＤがＧ００３であるギルドは、ＩＤがＵ００1、Ｕ０３０およびＵ１２１であるユーザのプレイヤキャラクタを構成員とし、ＩＤがＣ００３、Ｃ０１９およびＣ１４２である共有キャラクタを共有している。ギルドデータ１１２の存在により、本実施形態に係るゲームシステムのゲームサーバ１は、ユーザデータ１１０と共有キャラクタデータ１１１とを適切に対応させることが可能である。

（貢献度データ）
図５は、管理データのうちの貢献度データ１１３の例を示す図である。貢献度データ１１３は、ギルドを構成するプレイヤキャラクタごとの貢献度を、共有キャラクタのＩＤごとに計算したものである。本実施形態においては、図５に示されるように、共有キャラクタの各レベルでの貢献度が計算され、全レベル（全体）での貢献度も計算されている。例えば、特定のレベルでの貢献度によって属性の変化の大きさ、方向が決まる場合には、そのレベルでの貢献度が参照されて、それ以外の場合には全レベル（全体）での貢献度が参照されてもよい。なお、共有キャラクタのＩＤは共有キャラクタデータ１１１と同様である。

図５を用いていくつかの具体例を説明する。例えばＩＤがＣ００１である共有キャラクタは、その属性が初期状態（育てられていない状態）であって、レベルによらず貢献度はどのユーザも０％である。また、例えばＩＤがＣ００２である共有キャラクタについて、レベル１のときにはＩＤがＵ０８３のユーザのプレイヤキャラクタの貢献度が最も高く、レベル２ではＩＤがＵ００３のユーザのプレイヤキャラクタの貢献度の方が高いことがわかる。このようなレベル別の貢献度は次のような場合に参照される。例えば、この共有キャラクタの属性の変化の方向が、レベル１のときに貢献度が最も高いプレイヤキャラクタのジョブに影響を受ける（ジョブが職人ならばタイプＣになり、それ以外はタイプＡとなる）とする。このとき、本実施形態に係るゲームシステムのゲームサーバ１は、貢献度データ１１３のレベル１の貢献度を参照し、ユーザデータ１１０から該当するジョブを容易に判定して、属性の変化の方向を決定することが可能である。

（情報処理装置の処理）
図６は本実施形態に係るゲームシステムのゲームサーバ１が、通信端末２に対して配信するゲームの対戦画面の例を示す図である。このような対戦画面が、味方ギルドＡのユーザが用いる通信端末２の表示部２１に表示される。この対戦画面ではギルド同士の対戦が行われており、味方ギルドＡという表示９０ａの側（紙面左方）に味方のギルドメンバーが配置されており、敵ギルドＢという表示９０ｂの側（紙面右方）に敵のギルドメンバーが配置されている。

味方のギルドメンバーは、ＩＤがＵ００１、Ｕ０３０、Ｕ０９８、Ｕ１２１のユーザであって、それぞれのプレイヤキャラクタ９１ａ、９１ｂ、９１ｃ、９１ｄおよびステータス９２ａ、９２ｂ、９２ｃ、９２ｄが対戦画面に表示されている。また、敵のギルドメンバーは、ＩＤがＥ００１、Ｅ００２、Ｅ００３、Ｅ００４のユーザであって、それぞれのプレイヤキャラクタ９３ａ、９３ｂ、９３ｃ、９３ｄおよびステータス９４ａ、９４ｂ、９４ｃ、９４ｄが対戦画面に表示されている。この対戦において、味方ギルドＡはペットＣ００３を召喚して（表示９０ｃ）対戦に参加させている。そして、図６に示されるように、ペットＣ００３のキャラクタ９６は、敵のギルドメンバーを攻撃している。

一般に、ペットＣ００３のようにユーザのプレイヤキャラクタ以外のキャラクタを召喚して対戦させることで、例えば味方ギルドＡの弱点を補って、対戦を有利に進めることが可能である。前記のように、ペットＣ００３は貢献度に応じて属性の変化の大きさ、方向が変化する。そのため、ペットＣ００３を希望通りに育てるには戦略性が必要である。このことで、ギルド内で非対戦時でも交流が活発化し、ペットＣ００３を育成するためにギルドへの参加を希望するユーザが増えることも期待される。また、共有キャラクタがペット以外（例えば船などの移動体や城などの建物）であっても、外観を味方ギルドＡに固有の装飾にするという楽しみ方もある。この場合も、どのユーザのプレイヤキャラクタがアイテムを使用するかによって共有キャラクタの属性の変化の大きさ、方向が変化する。よって、このことに関して戦略が必要であり、継続的にギルド内での交流が活発化することが期待される。また、装飾デザインを楽しみとするユーザがギルドへ参加することも期待できる。

図７は本実施形態に係るゲームシステムのゲームサーバ１が、通信端末２に対してゲームを配信する際の処理を示すフローチャートである。

ステップＳ１では、ゲームサーバ１は通信端末２のユーザのプレイヤキャラクタに共有キャラクタを付与する。共有キャラクタは、付与条件が満たされる場合に、通信端末のユーザのプレイヤキャラクタに付与される。したがって、ゲームサーバ１は、付与条件が満たされか否かについての判定も行う。図７の例において、付与条件は通信端末２のユーザがゲームに参加することであるとする。ゲームサーバ１は、通信端末２から、ユーザ操作についての情報を受けとり、付与条件が満たされたタイミングで共有キャラクタを付与する。

ステップＳ２では、ゲームサーバ１の第１の管理部３１が、ユーザデータ１１０、ギルドデータ１１２を更新する。また、ゲームサーバ１の第２の管理部３２が、共有キャラクタデータ１１１を更新する。具体的には、ユーザデータ１１０、ギルドデータ１１２の共有キャラクタ、および共有キャラクタデータ１１１のギルドについて更新され、共有キャラクタの付与およびギルド内での共有が反映される。

ステップＳ３では、ゲームサーバ１は共有者、すなわちギルドの構成員が共有キャラクタの属性を変化させる行動をするまで待機する（ステップＳ３のＮｏ）。そして、共有キャラクタの属性を変化させる行動がある場合には（ステップＳ３のＹｅｓ）、ステップＳ４に進む。このステップにおいて、ゲームサーバ１は具体的には以下のような判定を行う。ゲームサーバ１は、ギルドを構成するプレイヤキャラクタのユーザの通信端末２から、ユーザ操作についての情報を受けとる。そして、ユーザ操作の中に所持アイテムの使用（例えば、共有キャラクタにえさを与える等）が含まれていれば、共有キャラクタの属性を変化させる行動があると判定する。

ステップＳ４では、ゲームサーバ１の第１の管理部３１がユーザデータ１１０を更新する。また、ゲームサーバ１の第２の管理部３２が、共有キャラクタデータ１１１を更新する。具体的には、ユーザデータ１１０の所持アイテム、および共有キャラクタデータ１１１のレベルおよび経験値について更新される。なお、レベルおよび経験値に変化がない場合には、共有キャラクタデータ１１１を更新しなくてもよい。

ステップＳ５では、ゲームサーバ１が、共有キャラクタの属性を変化させたことへの貢献度を、ギルドを構成するプレイヤキャラクタごとに計算する。

ステップＳ６では、ゲームサーバ１が、貢献度の計算結果を、共有キャラクタの属性の変化の大きさおよび方向に反映させる。つまり、ギルドを構成するプレイヤキャラクタの新たな貢献度に応じて、共有キャラクタの属性の変化の大きさおよび方向を決定する。このとき、例えば共有キャラクタの属性の変化の大きさに影響を与えないことが明らかな場合には、方向のみについて決定すればよい。つまり、大きさおよび方向の少なくとも一方について決定すればよい。そして、ゲームサーバ１の第２の管理部３２は、必要に応じて、共有キャラクタデータ１１１の属性の変化の大きさ、属性の変化の方向のデータを更新する。

ステップＳ７では、ゲームサーバ１が、プレイヤキャラクタの対戦におけるステータス、およびプレイヤキャラクタが対戦等において用いる共有キャラクタのステータスを、ステップＳ５で計算された貢献度に応じて変化させる。このとき、例えばプレイヤキャラクタの対戦等におけるステータスに影響を与えないことが明らかな場合には、共有キャラクタのステータスのみについて変化させればよい。つまり、プレイヤキャラクタのステータスおよび共有キャラクタのステータスの少なくとも一方を変化させればよい。具体的には、ゲームサーバ１の第１の管理部３１がユーザデータ１１０のステータスについて更新する。また、ゲームサーバ１の第２の管理部３２が、共有キャラクタデータ１１１のステータスについて更新する。なお、プレイヤキャラクタのステータスおよび共有キャラクタのステータスに変化がない場合には、ユーザデータ１１０および共有キャラクタデータ１１１の更新は実行されなくてもよい。

ステップＳ８では、ゲームサーバ１の第３の管理部３３が、貢献度データ１１３を更新して、ステップＳ５での計算結果を反映する。

以上のように、本実施形態のゲームサーバ１、ゲームシステムの制御方法、およびそのプログラムでは、通信端末２のユーザのプレイヤキャラクタに、そのプレイヤキャラクタを含んで構成されるギルドで共有される共有キャラクタを付与し、ギルドを構成するプレイヤキャラクタの行動に応じて、共有キャラクタの属性を変化させる。ギルドで共有された共有キャラクタは、所有者であるプレイヤキャラクタの行動のみならず、ギルドを構成する他のプレイヤキャラクタの行動に応じても属性が変化する。共有キャラクタの属性の変化の大きさ、方向等が、所有者であるプレイヤキャラクタの行動のみで決まらないため、ギルドとして戦略的に共有キャラクタを育てる（属性を変化させる）必要がある。そのため、本実施形態のゲームサーバ１、ゲームシステムの制御方法、およびそのプログラムでは、共有キャラクタの育成をギルド内の共通の目的として提供し、ユーザのギルド内での交流を盛んにすることができる。また、この共通の目的の達成のためには、例えば対戦時だけでなく非対戦時においても継続的に戦略性を発揮することが必要となる。

本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各ブロック及びステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数のブロック及びステップを１つに組み合わせたり、或いは分割したりすることが可能である。

例えば、ゲームの進行画面を、ゲームサーバ１が生成したデータに基づき通信端末２にて表示されるウェブ表示とし、その他のメニュー画面等を通信端末２にインストールされているネイティブアプリによって表示する等の、ゲームサーバ１及び通信端末２のそれぞれが処理の一部を担うハイブリッドアプリとすることもできる。

また、前記の実施形態において、共有キャラクタの属性はギルドを構成する全てのプレイヤキャラクタの行動に影響される。しかし、例えばゲーム進行上の演出として、共有キャラクタの属性に影響を与えるギルドの構成員を選択するようにしてもよい。この選択の過程で、さらにギルド内での話し合いが行なわれ、対戦場面以外での戦略性が発揮される。また、対戦におけるアイテムの使用（またはペナルティ）によって、特定のプレイヤキャラクタが共有キャラクタの属性に影響を与えられなくなってもよい。このとき、戦略を見直す必要が生じ得るため、さらにギルド内での話し合いが行なわれることになる。

また、前記の実施形態において、共有キャラクタを使用する場合、プレイヤキャラクタのステータスも貢献度に応じて強化される。ここで、共有キャラクタの召喚が可能である場合には、その召喚可能な回数をステータスに含めてもよい。つまり、貢献度の高いプレイヤキャラクタが、その共有キャラクタを対戦に召喚する場合には、通常よりも召喚可能な頻度を高くしてもよい（すなわち召喚可能回数を増やしてもよい）。このとき、どのユーザが共有キャラクタを召喚するかで対戦の有利さが変化するため、ギルドとしての戦略が必要になり、ギルド内での交流の活発化が期待できる。

１ ゲームサーバ
２ 通信端末
１０ サーバ通信部
１１ 記憶部
１５ サーバ制御部
２０ 端末通信部
２１ 表示部
２２ 操作部
２４ 端末制御部
３１ 第１の管理部
３２ 第２の管理部
３３ 第３の管理部
９１ａ〜９１ｄ プレイヤキャラクタ
９２ａ〜９２ｄ ステータス
９３ａ〜９３ｄ プレイヤキャラクタ
９４ａ〜９４ｄ ステータス
１１０ ユーザデータ
１１１ 共有キャラクタデータ
１１２ ギルドデータ
１１３ 貢献度データ

Claims (6)

1. 共有キャラクタデータを含む記憶部を備え、通信端末に対してゲームを提供するコンピュータに、
   前記通信端末のユーザのプレイヤキャラクタを含んで構成されるグループと、前記グループで共有される共有キャラクタとを、前記共有キャラクタデータで関連付けて、前記記憶部に記憶させるステップと、
   前記グループを構成するプレイヤキャラクタの行動に応じて、前記共有キャラクタの有する属性の少なくとも一つを変化させて、変化した属性について前記共有キャラクタデータを更新する第１更新ステップと、
   前記共有キャラクタの属性を変化させたことへの貢献度を、前記グループを構成するプレイヤキャラクタごとに計算するステップと、
   前記貢献度が最も高いプレイヤキャラクタの種類に応じて、前記共有キャラクタの属性の変化の大きさおよび方向の少なくとも一方について決定を行い、前記決定が反映されるように前記共有キャラクタデータを更新する第２更新ステップと、
   を実行させるためのプログラム。
2. 前記第２更新ステップは、前記共有キャラクタの所定のレベルにおける前記貢献度を用いて前記決定を行う、請求項１に記載のプログラム。
3. 前記ゲームは対戦ゲームであって、
   前記コンピュータに、
   前記プレイヤキャラクタの対戦におけるステータス、および前記プレイヤキャラクタが対戦において用いる前記共有キャラクタのステータスの少なくとも一方を、前記グループを構成するプレイヤキャラクタの貢献度に応じて変化させるステップ、
   を更に実行させる、請求項１または２に記載のプログラム。
4. 前記コンピュータに、
   所定の条件が満たされる場合に、前記通信端末のユーザに報酬を付与するステップ、
   を更に実行させて、
   前記第１更新ステップにおいて、前記通信端末のユーザが前記報酬を用いることで、前記共有キャラクタの属性が変化する、請求項１から３のいずれか１項に記載のプログラム。
5. 通信端末に対してゲームを提供する情報処理装置であって、
   共有キャラクタデータを含む記憶部と、
   前記通信端末のユーザのプレイヤキャラクタを含んで構成されるグループと、前記グループで共有される共有キャラクタとを、前記共有キャラクタデータで関連付けて、前記記憶部に記憶させる、第２の管理部と、
   前記共有キャラクタの属性を変化させたことへの貢献度を、前記グループを構成するプレイヤキャラクタごとに計算する、第３の管理部と、を備え、
   前記第２の管理部は、
   前記グループを構成するプレイヤキャラクタの行動に応じて、前記共有キャラクタの有する属性の少なくとも一つを変化させて、変化した属性について前記共有キャラクタデータを更新し、
   前記貢献度が最も高いプレイヤキャラクタの種類に応じて、前記共有キャラクタの属性の変化の大きさおよび方向の少なくとも一方について決定を行い、前記決定が反映されるように前記共有キャラクタデータを更新する、
   情報処理装置。
6. 通信端末と、共有キャラクタデータを含む記憶部を備え、前記通信端末に対してゲームを提供する情報処理装置と、を含むゲームシステムの制御方法であって、
   前記通信端末のユーザのプレイヤキャラクタを含んで構成されるグループと、前記グループで共有される共有キャラクタとを、前記共有キャラクタデータで関連付けて、前記記憶部に記憶するステップと、
   前記グループを構成するプレイヤキャラクタの行動に応じて、前記共有キャラクタの有する属性の少なくとも一つを変化させて、変化した属性について前記共有キャラクタデータを更新するステップと、
   前記共有キャラクタの属性を変化させたことへの貢献度を、前記グループを構成するプレイヤキャラクタごとに計算するステップと、
   前記貢献度が最も高いプレイヤキャラクタの種類に応じて、前記共有キャラクタの属性の変化の大きさおよび方向の少なくとも一方について決定を行い、前記決定が反映されるように前記共有キャラクタデータを更新するステップと、
   を含む、ゲームシステムの制御方法。

Images