【文献】
ギルドペット,RedStoneメモ帳,2014年 9月 1日,アーカイブ日:2013年11月12日,URL,http://web.archive.org/web/20131112145830/http://www21.atwiki.jp/rswithsora/pages/131.html
【文献】
ミニペット,RedStoneメモ帳,2014年 9月 1日,アーカイブ日:2013年7月23日,URL,http://web.archive.org/web/20130723145226/http://www21.atwiki.jp/rswithsora/pages/151.html
(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0015】
(システム全体構成)
以下、本発明の実施形態について説明する。
図1は、本発明の一実施形態に係るゲームシステムのブロック図である。ゲームシステムは、情報処理装置と、複数の通信端末2と、を備える。本実施形態において、情報処理装置はゲームサーバ1である。また、
図1では簡便のため、通信端末2は1つのみ図示している。
【0016】
ゲームサーバ1は、通信端末2に対してゲームを配信する。このゲームにおいて、通信端末2のユーザのプレイヤキャラクタはグループ(チーム)を構成できる。本実施形態において、ゲームサーバ1が配信するゲームは対戦ゲームであって、ゲーム内で構成されるグループ(チーム)をギルドと呼ぶ。本実施形態において、通信端末2のユーザは、プレイヤキャラクタの行動を決定し、対戦相手(例えば、敵キャラクタ)との対戦を行う。対戦は、例えばプレイヤキャラクタが敵キャラクタに遭遇する等、ゲーム中において所定の対戦イベントが発生した場合に行われる。また、本実施形態において、対戦は味方のプレイヤキャラクタの属するギルドと、敵キャラクタの属するギルドとの間(GVG:Guild versus Guild)で行われるが、ギルドの構成員の人数は複数に限らず1人であってもよい。また、ギルドは1人のユーザが結成を他のユーザに呼びかけて結成されるものであってもよいし、ユーザが自動的にギルドに配属されることで結成されるものであってもよい。なお、ゲームサーバ1が配信するゲームの種類は、対戦ゲームに限定されるものではない。
【0017】
ゲームサーバ1は、サーバ通信部10と、記憶部11と、サーバ制御部15と、第1の管理部31と、第2の管理部32と、第3の管理部33と、を備える。
【0018】
サーバ通信部10は通信端末2と通信する。本実施形態において、サーバ通信部10は、通信端末2と無線で通信するが、有線によって通信してもよい。また、サーバ通信部10は、無線通信と有線通信とを併用可能または選択可能であってもよい。
【0019】
記憶部11は、ユーザデータ110、共有キャラクタデータ111、ギルドデータ112、および貢献度データ113(以下、まとめて管理データともいう)を記憶する。本実施形態において、それぞれのデータはテーブル形式で記憶部11に記憶されるが、詳細については後述する。
【0020】
サーバ制御部15は、ゲームサーバ1の各種動作及びゲーム全体の進行を制御する。サーバ制御部15は、ユーザが対戦する対戦相手を決定し、サーバ通信部10を介して、種々のゲーム画面を表示させる指示を通信端末2に送信する。また、サーバ制御部15は、ゲームの適切な進行のため、第1の管理部31、第2の管理部32、および第3の管理部33を制御して、ユーザデータ110、共有キャラクタデータ111、ギルドデータ112、および貢献度データ113の管理(例えば値の更新等)を実行させる。
【0021】
通信端末2は、端末通信部20と、表示部21と、操作部22と、端末制御部24と、を備える。
【0022】
端末通信部20はゲームサーバ1と通信する。本実施形態において、端末通信部20は、ゲームサーバ1と無線で通信するが、有線によって通信してもよい。また、端末通信部20は、無線通信と有線通信とを併用可能または選択可能であってもよい。
【0023】
表示部21は、ゲームサーバ1から提供されるゲームの進行に応じて、ゲーム画面の表示を行う。例えば、表示部21は、味方および敵のギルドのメンバーと、各メンバーのステータス等が表示された対戦画面を表示してもよい。また、例えば、表示部21は、味方のギルドのメンバーが、船で次の目的地に向かって移動している画面を表示してもよい。表示部21には、液晶ディスプレイや有機ELディスプレイ等、任意の表示デバイスを採用可能である。
【0024】
操作部22は、ゲームに対して行われるユーザ操作を受け付ける。そして、操作部22は、受け付けたユーザ操作に応じた入力信号を端末制御部24に渡す。操作部22には、ボタンやタッチパネル等、任意の入力インターフェースを採用可能である。以下において、操作部22はタッチパネルであるとして説明する。
【0025】
端末制御部24は、通信端末2の各種動作を制御する。また、端末制御部24は、表示部21に表示される各種画面において受け付けたユーザ操作に応じた入力信号を操作部22から取得すると、端末通信部20を介して当該入力信号をゲームサーバ1に送信する。
【0026】
(共有キャラクタ)
本実施形態に係るゲームシステムのゲームサーバ1は、味方のギルドと敵のギルドとの対戦を行うゲームを提供するが、このゲームにおいて味方のギルドは対戦におけるグループ(チーム)だけではなく、共有キャラクタを成長、変化させるためのグループ(チーム)となる。共有キャラクタは例えば生き物(ペット等)、移動体(乗り物等)、建物等であるが、成長、変化可能な共有物であれば特に限定されるものではない。
【0027】
共有キャラクタは、付与条件が満たされる場合に、通信端末のユーザのプレイヤキャラクタに付与される。例えば、共有キャラクタは、ゲームをスタートするときにプレイヤキャラクタに自動的に付与されてもよい。つまり、付与条件は通信端末2のユーザがゲームに参加することであってもよい。また、別の例として、付与条件はプレイヤキャラクタがゲーム内で特定の地点に到達すること、または特定の対戦に勝利すること等であってもよい。
【0028】
このとき、付与される共有キャラクタは、ある特定のプレイヤキャラクタに所有され、その属性は初期状態である。例えば共有キャラクタがペット等の生き物であれば孵化する前の卵として付与されてもよい。また、例えば共有キャラクタが移動体であれば、エンジンや防護装備のグレードが最も低い状態で付与されてもよい。また、例えば共有キャラクタが建物であれば、外壁が単一色で装飾性のない状態で付与されてもよい。ここで属性とは、共有キャラクタが備える成長要素を含む性質のことである。属性としては、例えば対戦能力(レベル、攻撃力、防御力等)、外観、動作および性能等が挙げられるが、本実施形態においては、共有キャラクタの区分に応じて属性が定められる。例えば共有キャラクタがペットであれば、その属性は対戦能力および外観の少なくとも一つである。また、例えば共有キャラクタが建物であれば、その属性は外観である。ゲームサーバ1は、属性の変化(成長)を、パラメータ(例えばレベル)の数値と対応させて管理する。
【0029】
共有キャラクタは、それを所有するプレイヤキャラクタが属するギルド、つまり、そのプレイヤキャラクタを含んで構成されるギルドで共有され得る。ギルドで共有された共有キャラクタは、後述するように所有者であるプレイヤキャラクタの行動のみならず、ギルドを構成する他のプレイヤキャラクタの行動によっても属性が変化する。共有キャラクタの属性の変化の大きさ、方向等が、所有者であるプレイヤキャラクタの行動のみで決まらないため、ギルドとして戦略的に共有キャラクタを育てる(属性を変化させる)必要がある。言い換えると、共有キャラクタを希望通りに育てるという共通の目的を達成するためには、ギルド内で盛んに交流を行い、対戦場面だけでなく継続的に戦略性を発揮する必要が生じる。
【0030】
また、ギルドで共有される共有キャラクタの数に上限が設けられていてもよい。例えば、ギルドを5人以上のプレイヤキャラクタで構成し、各プレイヤキャラクタが1つ以上の共有キャラクタを有しているとする。このとき、ギルドで共有可能な共有キャラクタの上限が4つであれば、ゲームの進行上、有利な共有キャラクタを選択するために、ギルド内で戦略の検討が行われる可能性が高くなる。なお、以下においては、ギルドで共有される共有キャラクタの数に特に上限はなく、ギルドメンバーが所有する共有キャラクタは自動的にギルドで共有されるものとして説明する。
【0031】
(管理部について)
本実施形態に係るゲームシステムのゲームサーバ1は、ギルドで共有される共有キャラクタに関連して、第1の管理部31、第2の管理部32、および第3の管理部33を用いて、記憶部11に記憶されたユーザデータ110、共有キャラクタデータ111、ギルドデータ112、および貢献度データ113を管理する。
【0032】
第1の管理部31は、ユーザおよびそのプレイヤキャラクタに関する情報を主に管理するブロックであって、後述するようにユーザデータ110、ギルドデータ112等を必要に応じて更新する。
【0033】
第2の管理部32は、共有キャラクタのアップグレード(成長、変化)に関する情報を主に管理するブロックであって、後述するように共有キャラクタデータ111等を必要に応じて更新する。
【0034】
第3の管理部33は、共有キャラクタの属性を変化させたことへの貢献度を主に管理するブロックであって、後述するように貢献度データ113等を必要に応じて更新する。本実施形態において、貢献度とは、あるプレイヤキャラクタが共有キャラクタのアップグレードにどの程度貢献したかを相対的に示す数値である。例えば、ギルドのメンバーのうちで、あるプレイヤキャラクタのみが、ペットである共有キャラクタにえさ(例えば、食料アイテム)を与えて育てたとする。このとき、共有キャラクタの成長に関して、えさを与えたプレイヤキャラクタの貢献度は100%であって、他のプレイヤキャラクタの貢献度は0%である。
【0035】
ここで、第1の管理部31、第2の管理部32、および第3の管理部33の全てまたは一部を併合して1つのブロックとしてもよい。逆に、第1の管理部31、第2の管理部32、および第3の管理部33の全てまたは一部について、更にブロックを分けてもよい。また、ゲームサーバ1は、記憶部11に記憶されるプログラムに従って動作するコンピュータであって、第1の管理部31、第2の管理部32、および第3の管理部33の全てまたは一部がソフトウェアで実現されてもよい。例えば、記憶部11に記憶されるプログラムが、コンピュータを第1の管理部31、第2の管理部32、および第3の管理部33として機能させてもよい。
【0036】
(ユーザデータ)
図2は、管理データのうちのユーザデータ110の例を示す図である。ユーザデータ110では、通信端末のユーザを一意に識別可能なID(例えばU001)で区別した上で、IDと対応づけて、“レベル”、“経験値”、“所持金”、“共有キャラクタ”、“所持アイテム”、“ジョブ”、“ステータス”のパラメータについてテーブル管理している。また、パラメータは
図2に示されるものに限られず、例えばプレイ時間、武器や防具といった装備の情報等を更に含んでもよいし、逆に一部のパラメータが省略されていてもよい。ユーザデータ110は、主として第1の管理部31によって管理される。
【0037】
ユーザのIDは、本実施形態においては“U”の文字に3桁の数字を組み合わせているが、これに限られるものではない。例えば、ユーザを一意に識別可能であるならば、ユーザが任意に設定したプレイヤキャラクタ名としてもよい。なお、本実施形態においては1人のユーザは1つのプレイヤキャラクタを操作するとして説明する。“レベル”は、ゲーム内におけるプレイヤキャラクタの成長度を示すパラメータであり、レベルの数値が高いほど成長度が高いことを示す。“経験値”は、レベルの上昇に寄与するパラメータであり、ゲームの進行や対戦等に応じて加算される。本実施形態において、経験値が100%に達すると、レベルが上昇する。このとき、新しいレベルに設定されると共に経験値は0%にリセットされる。“所持金”は、ユーザが所持するゲーム内通貨を示すパラメータであり、ゲームの進行や対戦等に応じて加算される。ゲーム内通貨は、本発明の報酬となり得るものであり、後述するアイテムの購入に用いることができる。なお、報酬とは、それを所有または使用することによりゲームを進める上で有用な効果を生じさせるものをいう。
【0038】
“共有キャラクタ”は、前記のようにプレイヤキャラクタによって所有されるが、そのプレイヤキャラクタが属するギルドで共有される。共有キャラクタは、本実施形態においては“C”の文字に3桁の数字を組み合わせたIDで区別される。例えば、IDがU003であるユーザは、IDがC002である共有キャラクタを所有している。
【0039】
“所持アイテム”は、ユーザが所持しているアイテムである。アイテムは本発明の報酬の一種であり、ユーザがギルドを構成するプレイヤキャラクタを操作することで、ギルドで共有している共有キャラクタに対してアイテムを用いて、その共有キャラクタの属性を変化させることができる。例えばIDがU001であるユーザは、IDがC003である共有キャラクタ(後述するように区分はペット)のえさを所持しており、えさを与えることで共有キャラクタの有する属性(例えば対戦能力および外観)の少なくとも一つを変化させることができる。また、例えばIDがU002であるユーザは、IDがC001である共有キャラクタ(後述するように区分は建物)の装飾Aを所持しており、装飾Aを施すことで共有キャラクタの有する属性(例えば外観)を変化させることができる。また、例えばIDがU003であるユーザは、IDがC002である共有キャラクタ(後述するように区分は移動体)のエンジンFを所持しており、エンジンFに交換することで共有キャラクタの有する属性(例えば移動速度および移動可能範囲といった性能)の少なくとも一つを変化させることができる。
【0040】
ここで、ユーザは、所定の条件が満たされる場合にアイテムを付与される。ここで、所定の条件は、例えば対戦に勝利することであってもよいし、アイテムを購入したことであってもよい。対戦で得られるアイテムは、例えば勝負をする両ギルドが賭けてもよいし(敗者負担)、勝利の賞品として提供されてもよい。特に、対戦によってアイテムを賭ける場合には、何を賭けるか等についてギルドとしての戦略が必要になり、ギルド内での交流の活発化が期待できる。また、対戦に勝利して得られたアイテムを誰の所有物とするかを話し合いで決めることができれば、さらにギルド内での交流の活発化が期待できる。なお、アイテムとは完成品にかぎらず、その一部(例えばかけら)であってもよい。
【0041】
“ジョブ”は、プレイヤキャラクタのゲーム内での職業属性を表し、共有キャラクタの属性の変化の大きさ、方向等に影響を与えることがある。属性の変化の大きさ、方向が変化する条件は、共有キャラクタごとに定められている。例えばペットである共有キャラクタは、ジョブが戦士であるプレイヤキャラクタからえさをもらう場合にレベルがアップするスピードが速まってもよい。また、ペットである共有キャラクタは、ジョブが魔法使いであるプレイヤキャラクタからえさをもらう場合に魔法が使えるように変化してもよい。また、例えば移動体である共有キャラクタは、ジョブが職人であるプレイヤキャラクタがアイテムを使用した場合に移動速度が一層強化されてもよい。また、移動体である共有キャラクタは、ジョブが戦士であるプレイヤキャラクタがアイテムを使用した場合に防御力が一層高まってもよい。したがって、どのジョブのプレイヤキャラクタが共有キャラクタの属性を変化させるのに貢献する(以下、共有キャラクタを「育てる」とも表現する)かは、共有キャラクタの属性の将来的な変化に影響する。そのため、誰が共有キャラクタを育てるかについてギルドとしての戦略が必要になり、ギルド内での交流の活発化が期待できる。
【0042】
“ステータス”は、共有キャラクタを対戦等で用いる場合における、プレイヤキャラクタのステータス(例えば攻撃力、防御力、ヒットポイント等)に対する影響を表す。
図2の一つの例では、IDがU001であるユーザのプレイヤキャラクタのステータスは、IDがC003である共有キャラクタを使用(例えば対戦で召喚)した場合に、通常よりも50%増加する。どのユーザが共有キャラクタを使用するかで対戦等での有利さが変化するため、ギルドとしての戦略が必要になり、ギルド内での交流の活発化が期待できる。
【0043】
(共有キャラクタデータ)
図3は、管理データのうちの共有キャラクタデータ111の例を示す図である。共有キャラクタデータ111では、共有キャラクタを一意に識別可能なID(例えばC001)で区別した上で、IDと対応づけて、“区分”、“レベル”、“経験値”、“ギルド”、“属性の変化の大きさ”、“属性の変化の方向”、“ステータス”のパラメータについてテーブル管理している。また、パラメータは
図3に示されるものに限られず、例えば対戦での召喚回数等の情報を更に含んでもよいし、逆に一部のパラメータが省略されていてもよい。共有キャラクタデータ111は、主として第2の管理部32によって管理される。
【0044】
共有キャラクタのIDは、本実施形態においては“C”の文字に3桁の数字を組み合わせているが、これに限られるものではない。“区分”は共有キャラクタのカテゴリーを示し、本実施形態では、生物であるペット、プレイヤキャラクタが移動の際に用いる乗り物である移動体、プレイヤキャラクタが住居または集合場所として用いる建物等がある。ペットには、例えば犬、猫等の愛玩動物だけでなく、プレイヤキャラクタが召喚することで対戦に参加する召喚獣が含まれてもよい。また、移動体は例えば船、車両、飛行機等が含まれてもよい。また、建物は例えばテント、ビル、城等が含まれてもよい。
【0045】
“レベル”は、ゲーム内における共有キャラクタの属性の成長度を示すパラメータである。レベルの数値が高いほど成長度が高いことを示す。
【0046】
“経験値”は、レベルの上昇に寄与するパラメータであり、アイテムの使用、対戦への参加等に応じて加算される。本実施形態において、経験値が100%に達すると、レベルが上昇する。このとき、新しいレベルに設定されると共に経験値は0%にリセットされる。
【0047】
“ギルド”は、共有キャラクタが共有されているギルドを示す。
図3の一つの例では、IDがC002である共有キャラクタは、IDがG001であるギルドに共有されている。つまり、IDがC002である共有キャラクタは、その所有者であるプレイヤキャラクタが属するギルドで共有されている。ここで、例えばギルドで共有される共有キャラクタの数に上限が設けられている場合などで、共有キャラクタがギルドに共有されていない状態のときには空欄であってもよい。
【0048】
“属性の変化の大きさ”は、共有キャラクタの属性がギルドを構成するプレイヤキャラクタの行動に応じて変化する際の変化量(成長の度合い)を定める。また、属性の変化の方向は、共有キャラクタの属性の変化の方向性(成長の方向性)を示す。“属性の変化の大きさ”および“属性の変化の方向”は、共有キャラクタの属性を変化させたことへの貢献度によって影響される。貢献度の具体例については後述する。
【0049】
“属性の変化の大きさ”について具体的に説明する。
図3の例では、IDがC002、C003である共有キャラクタについて、属性の変化の大きさがそれぞれ150%、50%になっている。そのため、IDがC002、C003である共有キャラクタは、それぞれ通常の1.5倍、半分の速さで成長、すなわちレベルアップする。
【0050】
“属性の変化の方向”について具体的に説明する。例えばIDがC001である共有キャラクタは、建物であって、外観の装飾性が増加するタイプA(typeA)と、防御力がアップするタイプBという成長の方向性があり、貢献度に応じて一つの方向に定まる。また、例えばIDがC002である共有キャラクタは、移動体であって、運搬できる人数等が増えるタイプAと、敵に遭遇する確率が低くなるタイプBと、移動スピードが速くなるタイプC(typeC)といった成長の方向性があり、貢献度によって一つの方向に定まる。また、例えばIDがC003である共有キャラクタは、ペットであって、打撃による攻撃力が強くなるタイプAと、攻撃タイプの魔法が強くなるタイプBと、回復タイプの魔法が強くなるタイプCと、一部に特化することなくバランスよく強化されるタイプDといった成長の方向性があり、貢献度によって一つの方向に定まる。
図3の例では、IDがC001、C002、C003である共有キャラクタは、それぞれタイプA、タイプC、タイプDの方向に成長する。ギルドは、例えば育てるプレイヤキャラクタを変更する(すなわち貢献度を変化させる)ことで、成長の度合いを向上させたり、共有キャラクタの属性の変化の方向を変えたりすることが可能である。つまり、今後の共有キャラクタの成長の方向性等に関してギルドとしての戦略が必要になり、ギルド内での交流の活発化が期待できる。
【0051】
“ステータス”は、共有キャラクタを対戦等で用いる場合における、共有キャラクタのステータス(例えば攻撃力、防御力、ヒットポイント等)に対する影響を表す。共有キャラクタのステータスは、例えば貢献度の高いユーザのプレイヤキャラクタによって召喚された場合に、通常よりも高くなってもよい。
図3の一つの例では、IDがC003である共有キャラクタのステータスは、IDがU001であるユーザのプレイヤキャラクタによって用いられる(例えば対戦中に召喚される)場合に通常よりも50%増加する。どのユーザが共有キャラクタを召喚するかで対戦の有利さが変化するため、ギルドとしての戦略が必要になり、ギルド内での交流の活発化が期待できる。
【0052】
(ギルドデータ)
図4は、管理データのうちのギルドデータ112の例を示す図である。ギルドデータ112では、ギルドを一意に識別可能なID(例えばG001)で区別した上で、IDと対応づけて、“ギルドメンバー”、“共有キャラクタ”のパラメータについてテーブル管理している。また、パラメータは
図4に示されるものに限られず、例えば構成人数の履歴の情報等を更に含んでもよい。ギルドデータ112は、主として第1の管理部31によって管理される。
【0053】
ギルドのIDは、本実施形態においては“G”の文字に3桁の数字を組み合わせているが、これに限られるものではない。“ギルドメンバー”はギルドを構成するメンバー(構成員)をユーザのIDを用いて示すものである。また、“共有キャラクタ”はギルドで共有される共有キャラクタを共有キャラクタのIDを用いて示すものである。例えば、IDがG003であるギルドは、IDがU001、U030およびU121であるユーザのプレイヤキャラクタを構成員とし、IDがC003、C019およびC142である共有キャラクタを共有している。ギルドデータ112の存在により、本実施形態に係るゲームシステムのゲームサーバ1は、ユーザデータ110と共有キャラクタデータ111とを適切に対応させることが可能である。
【0054】
(貢献度データ)
図5は、管理データのうちの貢献度データ113の例を示す図である。貢献度データ113は、ギルドを構成するプレイヤキャラクタごとの貢献度を、共有キャラクタのIDごとに計算したものである。本実施形態においては、
図5に示されるように、共有キャラクタの各レベルでの貢献度が計算され、全レベル(全体)での貢献度も計算されている。例えば、特定のレベルでの貢献度によって属性の変化の大きさ、方向が決まる場合には、そのレベルでの貢献度が参照されて、それ以外の場合には全レベル(全体)での貢献度が参照されてもよい。なお、共有キャラクタのIDは共有キャラクタデータ111と同様である。
【0055】
図5を用いていくつかの具体例を説明する。例えばIDがC001である共有キャラクタは、その属性が初期状態(育てられていない状態)であって、レベルによらず貢献度はどのユーザも0%である。また、例えばIDがC002である共有キャラクタについて、レベル1のときにはIDがU083のユーザのプレイヤキャラクタの貢献度が最も高く、レベル2ではIDがU003のユーザのプレイヤキャラクタの貢献度の方が高いことがわかる。このようなレベル別の貢献度は次のような場合に参照される。例えば、この共有キャラクタの属性の変化の方向が、レベル1のときに貢献度が最も高いプレイヤキャラクタのジョブに影響を受ける(ジョブが職人ならばタイプCになり、それ以外はタイプAとなる)とする。このとき、本実施形態に係るゲームシステムのゲームサーバ1は、貢献度データ113のレベル1の貢献度を参照し、ユーザデータ110から該当するジョブを容易に判定して、属性の変化の方向を決定することが可能である。
【0056】
(情報処理装置の処理)
図6は本実施形態に係るゲームシステムのゲームサーバ1が、通信端末2に対して配信するゲームの対戦画面の例を示す図である。このような対戦画面が、味方ギルドAのユーザが用いる通信端末2の表示部21に表示される。この対戦画面ではギルド同士の対戦が行われており、味方ギルドAという表示90aの側(紙面左方)に味方のギルドメンバーが配置されており、敵ギルドBという表示90bの側(紙面右方)に敵のギルドメンバーが配置されている。
【0057】
味方のギルドメンバーは、IDがU001、U030、U098、U121のユーザであって、それぞれのプレイヤキャラクタ91a、91b、91c、91dおよびステータス92a、92b、92c、92dが対戦画面に表示されている。また、敵のギルドメンバーは、IDがE001、E002、E003、E004のユーザであって、それぞれのプレイヤキャラクタ93a、93b、93c、93dおよびステータス94a、94b、94c、94dが対戦画面に表示されている。この対戦において、味方ギルドAはペットC003を召喚して(表示90c)対戦に参加させている。そして、
図6に示されるように、ペットC003のキャラクタ96は、敵のギルドメンバーを攻撃している。
【0058】
一般に、ペットC003のようにユーザのプレイヤキャラクタ以外のキャラクタを召喚して対戦させることで、例えば味方ギルドAの弱点を補って、対戦を有利に進めることが可能である。前記のように、ペットC003は貢献度に応じて属性の変化の大きさ、方向が変化する。そのため、ペットC003を希望通りに育てるには戦略性が必要である。このことで、ギルド内で非対戦時でも交流が活発化し、ペットC003を育成するためにギルドへの参加を希望するユーザが増えることも期待される。また、共有キャラクタがペット以外(例えば船などの移動体や城などの建物)であっても、外観を味方ギルドAに固有の装飾にするという楽しみ方もある。この場合も、どのユーザのプレイヤキャラクタがアイテムを使用するかによって共有キャラクタの属性の変化の大きさ、方向が変化する。よって、このことに関して戦略が必要であり、継続的にギルド内での交流が活発化することが期待される。また、装飾デザインを楽しみとするユーザがギルドへ参加することも期待できる。
【0059】
図7は本実施形態に係るゲームシステムのゲームサーバ1が、通信端末2に対してゲームを配信する際の処理を示すフローチャートである。
【0060】
ステップS1では、ゲームサーバ1は通信端末2のユーザのプレイヤキャラクタに共有キャラクタを付与する。共有キャラクタは、付与条件が満たされる場合に、通信端末のユーザのプレイヤキャラクタに付与される。したがって、ゲームサーバ1は、付与条件が満たされか否かについての判定も行う。
図7の例において、付与条件は通信端末2のユーザがゲームに参加することであるとする。ゲームサーバ1は、通信端末2から、ユーザ操作についての情報を受けとり、付与条件が満たされたタイミングで共有キャラクタを付与する。
【0061】
ステップS2では、ゲームサーバ1の第1の管理部31が、ユーザデータ110、ギルドデータ112を更新する。また、ゲームサーバ1の第2の管理部32が、共有キャラクタデータ111を更新する。具体的には、ユーザデータ110、ギルドデータ112の共有キャラクタ、および共有キャラクタデータ111のギルドについて更新され、共有キャラクタの付与およびギルド内での共有が反映される。
【0062】
ステップS3では、ゲームサーバ1は共有者、すなわちギルドの構成員が共有キャラクタの属性を変化させる行動をするまで待機する(ステップS3のNo)。そして、共有キャラクタの属性を変化させる行動がある場合には(ステップS3のYes)、ステップS4に進む。このステップにおいて、ゲームサーバ1は具体的には以下のような判定を行う。ゲームサーバ1は、ギルドを構成するプレイヤキャラクタのユーザの通信端末2から、ユーザ操作についての情報を受けとる。そして、ユーザ操作の中に所持アイテムの使用(例えば、共有キャラクタにえさを与える等)が含まれていれば、共有キャラクタの属性を変化させる行動があると判定する。
【0063】
ステップS4では、ゲームサーバ1の第1の管理部31がユーザデータ110を更新する。また、ゲームサーバ1の第2の管理部32が、共有キャラクタデータ111を更新する。具体的には、ユーザデータ110の所持アイテム、および共有キャラクタデータ111のレベルおよび経験値について更新される。なお、レベルおよび経験値に変化がない場合には、共有キャラクタデータ111を更新しなくてもよい。
【0064】
ステップS5では、ゲームサーバ1が、共有キャラクタの属性を変化させたことへの貢献度を、ギルドを構成するプレイヤキャラクタごとに計算する。
【0065】
ステップS6では、ゲームサーバ1が、貢献度の計算結果を、共有キャラクタの属性の変化の大きさおよび方向に反映させる。つまり、ギルドを構成するプレイヤキャラクタの新たな貢献度に応じて、共有キャラクタの属性の変化の大きさおよび方向を決定する。このとき、例えば共有キャラクタの属性の変化の大きさに影響を与えないことが明らかな場合には、方向のみについて決定すればよい。つまり、大きさおよび方向の少なくとも一方について決定すればよい。そして、ゲームサーバ1の第2の管理部32は、必要に応じて、共有キャラクタデータ111の属性の変化の大きさ、属性の変化の方向のデータを更新する。
【0066】
ステップS7では、ゲームサーバ1が、プレイヤキャラクタの対戦におけるステータス、およびプレイヤキャラクタが対戦等において用いる共有キャラクタのステータスを、ステップS5で計算された貢献度に応じて変化させる。このとき、例えばプレイヤキャラクタの対戦等におけるステータスに影響を与えないことが明らかな場合には、共有キャラクタのステータスのみについて変化させればよい。つまり、プレイヤキャラクタのステータスおよび共有キャラクタのステータスの少なくとも一方を変化させればよい。具体的には、ゲームサーバ1の第1の管理部31がユーザデータ110のステータスについて更新する。また、ゲームサーバ1の第2の管理部32が、共有キャラクタデータ111のステータスについて更新する。なお、プレイヤキャラクタのステータスおよび共有キャラクタのステータスに変化がない場合には、ユーザデータ110および共有キャラクタデータ111の更新は実行されなくてもよい。
【0067】
ステップS8では、ゲームサーバ1の第3の管理部33が、貢献度データ113を更新して、ステップS5での計算結果を反映する。
【0068】
以上のように、本実施形態のゲームサーバ1、ゲームシステムの制御方法、およびそのプログラムでは、通信端末2のユーザのプレイヤキャラクタに、そのプレイヤキャラクタを含んで構成されるギルドで共有される共有キャラクタを付与し、ギルドを構成するプレイヤキャラクタの行動に応じて、共有キャラクタの属性を変化させる。ギルドで共有された共有キャラクタは、所有者であるプレイヤキャラクタの行動のみならず、ギルドを構成する他のプレイヤキャラクタの行動に応じても属性が変化する。共有キャラクタの属性の変化の大きさ、方向等が、所有者であるプレイヤキャラクタの行動のみで決まらないため、ギルドとして戦略的に共有キャラクタを育てる(属性を変化させる)必要がある。そのため、本実施形態のゲームサーバ1、ゲームシステムの制御方法、およびそのプログラムでは、共有キャラクタの育成をギルド内の共通の目的として提供し、ユーザのギルド内での交流を盛んにすることができる。また、この共通の目的の達成のためには、例えば対戦時だけでなく非対戦時においても継続的に戦略性を発揮することが必要となる。
【0069】
本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各ブロック及びステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数のブロック及びステップを1つに組み合わせたり、或いは分割したりすることが可能である。
【0070】
例えば、ゲームの進行画面を、ゲームサーバ1が生成したデータに基づき通信端末2にて表示されるウェブ表示とし、その他のメニュー画面等を通信端末2にインストールされているネイティブアプリによって表示する等の、ゲームサーバ1及び通信端末2のそれぞれが処理の一部を担うハイブリッドアプリとすることもできる。
【0071】
また、前記の実施形態において、共有キャラクタの属性はギルドを構成する全てのプレイヤキャラクタの行動に影響される。しかし、例えばゲーム進行上の演出として、共有キャラクタの属性に影響を与えるギルドの構成員を選択するようにしてもよい。この選択の過程で、さらにギルド内での話し合いが行なわれ、対戦場面以外での戦略性が発揮される。また、対戦におけるアイテムの使用(またはペナルティ)によって、特定のプレイヤキャラクタが共有キャラクタの属性に影響を与えられなくなってもよい。このとき、戦略を見直す必要が生じ得るため、さらにギルド内での話し合いが行なわれることになる。
【0072】
また、前記の実施形態において、共有キャラクタを使用する場合、プレイヤキャラクタのステータスも貢献度に応じて強化される。ここで、共有キャラクタの召喚が可能である場合には、その召喚可能な回数をステータスに含めてもよい。つまり、貢献度の高いプレイヤキャラクタが、その共有キャラクタを対戦に召喚する場合には、通常よりも召喚可能な頻度を高くしてもよい(すなわち召喚可能回数を増やしてもよい)。このとき、どのユーザが共有キャラクタを召喚するかで対戦の有利さが変化するため、ギルドとしての戦略が必要になり、ギルド内での交流の活発化が期待できる。
【課題】戦略性の発揮が継続的に必要な共通の目的を提供して、ユーザのグループ内での交流を盛んにすることができるプログラム、情報処理装置、及びゲームシステムの制御方法を提供する。
【解決手段】プログラムであって、通信端末2に対してゲームを提供するコンピュータ(ゲームサーバ1)に、(a)通信端末2のユーザのプレイヤキャラクタに、プレイヤキャラクタを含んで構成されるグループで共有される共有キャラクタを付与するステップと、(b)グループを構成するプレイヤキャラクタの行動に応じて、共有キャラクタの有する属性の少なくとも一つを変化させるステップと、を実行させる。