JP5986541B2 - ゲーム管理装置、ゲーム端末装置、ゲームシステム及びプログラム - Google Patents

Description

本発明は、ゲームを管理するゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラムに関するものである。

従来から、インターネット上に設置されたゲームサーバに、ユーザの端末装置（パーソナルコンピュータ、携帯電話端末等）を接続することによって、ユーザがゲームサーバから提供される各種ゲームサービスを受けることができるゲームシステムがある（特許文献１等）。また、インターネットを介して共通のゲームをプレイするユーザ同士が、仲間関係を構築することができるゲームシステムも提案されている（特許文献２参照）。ゲーム内でユーザ同士が交流できるゲームは、いわゆるソーシャルゲームと称される。

そして近年、人と人とのつながりを促進・サポートするコミュニティ型のサービスであるソーシャルネットワーキングサービス（ＳＮＳ）が普及している。一般的なＳＮＳでは、ユーザは、自分が友達登録している相手と交流することができる。

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

ＳＮＳ等のコミュニティサービスはゲーム外のサービスであるため、ユーザがＳＮＳにおいて友達登録している相手とは、ＳＮＳで交流することはできても、その相手がゲームに登録していなければ、その相手とはゲームを通して繋がりを持つことはできなかった。

本発明は、上記の事情に鑑みてなされたものであり、その目的は、ユーザがコミュニティサービスにおいて交流している他のユーザとのつながりを、ゲーム内でも強めることができるゲームを提供することである。

１）本発明の一局面によるゲーム管理装置（1,2,501,503）は、第１ユーザと、当該第１ユーザと所定の関係がある複数の第２ユーザのそれぞれとの間で交流が可能なコミュニティサービスと連携してゲームを進行させるものであって、前記第１ユーザが利用するゲームにおける複数のキャラクタに、前記複数の第２ユーザの少なくとも一部をそれぞれ対応付ける対応付け手段（71）と、前記コミュニティサービスにおける前記第１ユーザと前記第２ユーザとの間の交流度合いを取得する取得手段（72）と、前記交流度合いに基づいて、前記第２ユーザと対応付けられたキャラクタのパラメータを変動させる変動手段（83）と、を備えている。

この構成のゲーム管理装置は、例えば各ユーザのゲーム端末（端末装置）と通信を行うことができるサーバなどの情報処理装置（コンピュータ）により構成することができる。あるいは、本ゲーム管理装置は、ゲーム端末としての情報処理装置により構成することもできる。あるいは、本ゲーム管理装置は、相互に通信する複数の情報処理装置（サーバ、ゲーム端末）により構成することもできる。

本ゲーム管理装置は、第１ユーザと所定の関係がある複数の第２ユーザのそれぞれとの間で交流が可能なコミュニティサービスと連携してゲームを進行させる。ここで、「所定の関係」とは、ユーザ間で交流可能となる関係であればよく、例えば、第１ユーザが交流相手として第２ユーザを登録（いわゆる友達リスト登録、アドレス帳登録等）している関係が挙げられる。あるいは、第２ユーザが第１ユーザを交流相手として登録しているような関係、または第１ユーザおよび第２ユーザの双方が互いに交流相手として登録し合っている関係であってもよい。前記所定の関係を、友達、フレンド、仲間等の呼称で表してもよい。

後述の１２）に示すように、コミュニティサービスにおける交流とは、第１ユーザと第２ユーザとの間で、ネットワークを介して、文字情報、画像情報または音声情報等が、一方的にまたは相互に伝達されることである。コミュニティサービスにおける交流には、例えば、通話、チャット、メッセージの送信、写真やイラスト画像の送信等の種々の交流を含めることができる。コミュニティサービスとしては、いわゆるソーシャルネットワーキングサービス（ＳＮＳ）、インターネット電話サービス、チャットサービス等を含む。

また、コミュニティサービスと連携してゲームを進行させるとは、ゲーム外サービスであるコミュニティサービスにおける情報を、ゲーム進行において参照したり利用したりできることを意味する。

本ゲーム管理装置では、対応付け手段が、第１ユーザが利用するゲームにおける複数のキャラクタ（それらの少なくとも一部）に、前記複数の第２ユーザの少なくとも一部をそれぞれ対応付ける。野球ゲームを例に挙げると、第１ユーザのゲーム内野球チームの複数の選手キャラクタには、コミュニティサービスにおいて第１ユーザと所定の関係がある複数の第２ユーザの少なくとも一部のそれぞれが対応付けられる。例えば、第１ユーザの交流相手である第２ユーザが３０人いる場合に、この中の９人を第１ユーザのゲーム内野球チームの選手キャラクタとして対応付けるのである。なお、対応付けは９人でなくても、１人でも数人でもよい。これにより、例えば、第１ユーザのゲーム内野球チームには、第２ユーザの名前（またはニックネーム、あるいはアバター画像等）が対応付けられたキャラクタが所属することになる。すなわち、第２ユーザは、第１ユーザのゲーム内グループのキャラクタと対応付けられることにより、仮想的に第１ユーザのゲーム内グループのメンバとなる。

ここで、第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザは、既にゲームに登録している第２ユーザに限定されない。すなわち、ゲームに登録していない第２ユーザであっても、第１ユーザのゲーム内キャラクタに対応付けることができる。なお、バリエーションとしては、第２ユーザの中でも、既にゲームに登録している第２ユーザのみを対象として、第１ユーザのゲーム内グループのキャラクタに対応付けることも可能である。第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザを選択する方法は、第１ユーザが手動で第２ユーザを選択してもよいし、後述する１１）の構成のように自動的に第２ユーザが選択されるようにしてもよい。

また、ゲーム管理装置の取得手段は、コミュニティサービスにおける第１ユーザと第２ユーザとの間の交流度合を取得する。例えば、取得手段は、コミュニティサービスにおける第１ユーザと第２ユーザの各々との間の交流情報（交流履歴等）に基づいて、交流度合い（交流回数、交流頻度、交流ポイント等）を求める。あるいは、コミュニティサービスにおいて交流度合いの情報が存在すれば、取得手段は、コミュニティサービスから交流度合いの情報を直接取得してもよい。

そして、ゲーム管理装置の変動手段は、取得手段によって取得された交流度合いに基づいて、第２ユーザと対応付けられたキャラクタのパラメータを変動させる。例えば、第１ユーザと第２ユーザとの間の交流度合いが大きいほど、その第２ユーザと対応付けられたキャラクタの能力を大きくする。また、ゲーム進行によってキャラクタ能力が向上するような構成の場合は、その向上率（向上の度合い）を前記交流度合いが大きいほど大きくなるようにしてもよい。

パラメータの変動とは、パラメータを向上させることに限定されず、パラメータを低下させるものであってもよい。例えば、第１ユーザと第２ユーザとの間の交流度合いが所定の閾値以上の場合には、閾値との差が大きいほど、その第２ユーザと対応付けられたキャラクタのパラメータを大きくする一方、前記交流度合いが閾値未満の場合には、閾値との差が大きいほど、その第２ユーザと対応付けられたキャラクタのパラメータを小さくしてもよい。

本構成により、第１ユーザは、コミュニティサービスにおける第２ユーザとの交流を積極的に行うように動機付けられる。このパラメータの変動は、一時的（例えば、１回のプレイのみ、１日だけ等）であるようにして、その後、変動前のパラメータに戻るようにしてもよいし、一度変動したパラメータは元に戻らないようにしてもよい。

通常、第１ユーザにとって、ＳＮＳ等のコミュニティサービスで通話やチャット等の交流を行う第２ユーザは、現実世界で繋がりのある間柄である。本構成では、コミュニティサービスにおいて交流している現実世界の第２ユーザが、第１ユーザのゲーム内キャラクタと対応付けられて、ゲームに登場する。これにより、第１ユーザは、ゲームを遊戯する毎に、自己のゲームに登場する第２ユーザのキャラクタを通して、間接的に親しみを感じることになる。そして、本構成では、コミュニティサービスにおける第１ユーザと第２ユーザとの交流度合いが評価されて、第１ユーザの利用するゲームにおいて、第２ユーザと対応付けられたキャラクタのパラメータが自動的に調整される。すなわち、コミュニティサービスにおける第１ユーザと第２ユーザとの交流が、第１ユーザのゲームに反映される。本構成により、第１ユーザは、ゲームを通しても、第２ユーザとのつながりを強め、延いてはゲームに対する関心と興味をより強める結果となる。よって、本ゲーム管理装置は、第１ユーザにとって飽きのこない継続性を有するゲームサービスの提供を実現できる。

２）上記の１）の構成において、前記取得手段（72）は、前記コミュニティサービスにおける前記第１ユーザと前記第２ユーザとの間の交流内容に応じた交流ポイントによって前記交流度合いを算出することが好ましい。

この構成によれば、コミュニティサービスにおける第１ユーザと第２ユーザとの間の交流度合いは、交流内容に応じた交流ポイントにより管理される。交流の内容に応じた交流ポイントの一例としては、通話：１０ポイント／回、メッセージの送信：５ポイント／回、イラスト画像の送信：２ポイント／回、等が挙げられる。通話は、第１ユーザがかなり親しい第２ユーザと行う現実世界の交流であることから、メッセージ送信やイラスト画像の送信よりも、１回の交流当たりのポイント大きくしている。また、相手に簡単に送信できるイラスト画像の送信よりも、メッセージの送信の交流ポイントを大きくしている。また、通話による交流ポイントは、通話時間によって値を変えてもよい（通話時間が長いほど交流ポイントを大きくする）。また、メッセージ送信による交流ポイントは、その文章の長さ（文字数）によって値を変えてもよい（文章が長いほど交流ポイントを大きくする）。このように、交流内容に応じて任意の交流ポイントを設定できる。そして、例えば、所定期間（例えば、過去１日、１週間、１か月等）における交流相手毎の交流ポイントの合計値によって、第１ユーザと第２ユーザの各々との間の交流度合いを算出することができる。本構成により、コミュニティサービスにおける現実世界の交流内容に応じた適切な交流度合いの評価が可能となる。

３）上記の２）の構成において、前記第１ユーザから前記第２ユーザに対して交流が行われた場合と、前記第２ユーザから前記第１ユーザに対して交流が行われた場合とで、前記交流ポイントを異ならせることが好ましい。

例えば、前者の場合の交流ポイントを、後者の場合の交流ポイントよりも大きくする。これは、第１ユーザ自らが第２ユーザに対して通話等の交流を行ったということは、第１ユーザがその第２ユーザに対して親しみを感じていることの表れであり、これを交流ポイントに反映させたものである。この場合、第１ユーザの方からよく交流をしている第２ユーザが、第１ユーザのゲーム内キャラクタと対応付けられ易くなる。

あるいは、逆に、後者の場合の交流ポイントを、前者の場合の交流ポイントよりも大きくしてもよい。これは、第２ユーザから第１ユーザに対して通話等の交流が行われたということは、第１ユーザがその第２ユーザから親しみを感じられていることの表れであり、これを交流ポイントに反映させたものである。この場合、第１ユーザに対してよく交流してくれる第２ユーザと対応付けられたキャラクタのパラメータが向上し易くなる。

４）上記の１）ないし３）の何れかの構成において、前記複数のキャラクタのそれぞれには、役割に応じた基本パラメータが予め設定されており、前記変動手段（83）は、前記交流度合いに基づいて、前記第２ユーザと対応付けられた前記キャラクタの前記基本パラメータを変動させることが好ましい。

野球ゲームを例に挙げると、クリーンナップ（打順の３番、４番、５番）のキャラクタについては、その基本パラメータ（パワー等の基本能力）を他の打順のキャラクタよりも高く設定しておく。この場合、クリーンナップのキャラクタのパラメータの向上は、高い基本パラメータをベースとすることになるので、実質的に、他のキャラクタよりも高いパラメータの向上を見込めることになる。従って、第１ユーザはゲームを有利に運ぶためには、特に、クリーンナップのキャラクタに対応付けられた第２ユーザと、コミュニティサービスでより多くの交流をするといった戦略をとれる。あるいは逆に、普段からコミュニティサービスでの交流が多い第２ユーザをクリーンナップのキャラクタに対応付けるようにしてもよい。本構成により、コミュニティサービスでの交流がゲーム戦略に及ぼす影響がより大きくなり、ゲームの興趣性をより高めることができる。

５）上記の４）の構成において、前記交流度合いに基づいて、前記第２ユーザと対応付けられた前記キャラクタの前記役割を決定する役割決定手段（74）をさらに備えていることが好ましい。

ここで、第２ユーザと対応付けられたキャラクタの役割を決定するとは、例えば攻撃・防御の順番、ポジション等の決定を言う。例えば、野球ゲームでは、攻撃の順番であるオーダー（打順）や、ポジション（守備位置）の決定が挙げられる。また、サッカーゲームでは、ポジション（ＧＫ，ＦＷ，ＭＦ，ＤＦ等）の決定が挙げられる。また、コマンドゲームでは、「実戦部隊」、「研究開発班」、「糧食班」、「医療班」、「諜報班」などの役割の決定が挙げられる。また、料理ゲームでは、シェフ（料理長）、パティシエ（デザート担当）、ソムリエ（ワイン担当）、フロアスタッフなどの役割の決定が挙げられる。

ここで、コミュニティサービスにおける第１ユーザと第２ユーザの各々との交流度合い（交流ポイント等）に基づいて、野球ゲームのオーダーを決定する場合を例示する。例えば、交流度合いが大きい第２ユーザと対応付けられたキャラクタを、クリーンナップまたは上位打線に自動的に設定する。一例を挙げると、交流度合いが大きい順に、４→３→５→１→２→６→７→８→９の打順に設定する。一旦、クリーンナップに設定された第２ユーザのキャラクタであっても、第１ユーザとその第２ユーザとのコミュニティサービスを利用した現実世界での交流が少なくなると、その第２ユーザのキャラクタの役割（打順）は、自動的に下位打線に変更される。

本構成により、第１ユーザがコミュニティサービスでよく交流している第２ユーザのキャラクタが、自動的に、第１ユーザの利用するゲーム内で重要な役割を担うようにすることができる。よって、第１ユーザにとっては、ゲームを通して、コミュニティサービスでよく交流している親しい第２ユーザとのつながりを、より強めることができる。

６）上記の１）ないし５）の何れかの構成において、前記コミュニティサービスにおける前記第２ユーザのプロフィール情報を取得するプロフィール情報取得手段（75）をさらに備え、前記変動手段（83）は、前記交流度合い及び前記プロフィール情報に基づいて、前記第２ユーザと対応付けられた前記キャラクタのパラメータを変動させることが好ましい。

７）上記の６）の構成において、前記プロフィール情報には、年齢、性別、趣味の少なくとも１つの情報が含まれることが好ましい。

通常、ＳＮＳ等のコミュニティサービスにおいて、各ユーザは、自分の名前、年齢、性別、出身地、住所、趣味等のユーザ自身の種々のプロフィール情報を登録している。そして、本構成では、コミュニティサービスにおいて第２ユーザのプロフィール情報を取得し、交流度合いだけではなく、プロフィール情報も考慮して、第２ユーザと対応付けられたキャラクタのパラメータを変動させる。例えば、野球ゲームにおいて、女性、子供（所定以下の年齢）、高齢者（所定以上の年齢）の第２ユーザに対応付けられたキャラクタについては、パラメータのパワーの値を本来の値よりも低下させる一方、ミートの値を本来の値よりも向上させる。これにより、ボールには当て易いが、長打にはなり難いようにする。あるいは、単純にパラメータのパワーの値を本来の値よりも低下させるだけでもよい。また、スポーツを趣味としている第２ユーザに対応付けられたキャラクタについては、パラメータのパワー、ミート等の値を本来の値よりも向上させるようにしてもよい。

このように、コミュニティサービスにおいて第２ユーザが登録している現実世界の年齢等の情報に基づいて、その第２ユーザに対応付けられたキャラクタの基本パラメータを変化させることにより、現実世界の第２ユーザの特定の属性を、ゲーム内の第２ユーザのキャラクタに反映させることができ、ゲームの興趣性を高めることができる。

８）上記の１）ないし７）の何れかの構成において、前記複数の第２ユーザの少なくとも一部のそれぞれと対応付けられた前記キャラクタの中に、前記コミュニティサービスにおいて前記第２ユーザ同士が前記所定の関係を有している２以上のキャラクタが存在する場合に、ゲーム上の特殊効果を発生させる特殊効果発生手段（84）をさらに備えていることが好ましい。

ここで、所定の関係とは、前述のようにコミュニティサービスにおいてユーザ間で交流可能となる関係であればよく、例えばＳＮＳのチャットルーム内のメンバの関係等も含まれる。

例えば、第１ユーザＡが利用するゲームの複数のキャラクタに、第２ユーザＢ、Ｃ、Ｄ…が対応付けられているものとする。そして、コミュニティサービスにおいて、第２ユーザＢ、Ｃ同士が前記所定の関係（第２ユーザ同士が交流可能となる関係）を有している場合に、第１ユーザＡのゲームにおいて、ゲーム上の特殊効果が発生する。

例えば、特殊効果として、第２ユーザＢ、Ｃに対応付けられているキャラクタの能力が一時的に向上する。なお、特殊効果は、能力の向上に限らず、キャラクタに新たな特殊能力（例えば、バットスイングが早くなる能力）を追加したり、キャラクタに装着する特殊アイテム（例えば、ホームランが出易いバット）を付与したりするものであってもよい。

ここでは、第２ユーザＢ、Ｃの２人が所定の関係である例を示したが、３人以上の第２ユーザＢ、Ｃ、Ｄ…が、コミュニティサービスにおいて互いに前記所定の関係である場合も、第１ユーザＡのゲームにおいて、ゲーム上の特殊効果が発生する。

第１ユーザＡにとって第２ユーザＢ、Ｃ、Ｄ…は、コミュニティサービスで交流する現実世界の友達等の関係である。よって、第１ユーザＡは、例えば第２ユーザＢ・Ｃ同士が交流可能な所定の関係であるか否かは知っていることが多い。従って、第１ユーザＡはゲームを有利に運ぶためには、所定の関係を有する２人以上の第２ユーザを、自分のゲーム内キャラクタに対応付けるという戦略をとれる。本構成により、ゲームの興趣性をより高めることができる。

９）上記の１）ないし７）の何れかの構成において、前記ゲームは、前記複数のキャラクタのプレイ順序を予め定めることができるゲームであり、前記複数の第２ユーザの少なくとも一部のそれぞれと対応付けられた前記キャラクタの中に、前記コミュニティサービスにおいて前記第２ユーザ同士が前記所定の関係を有している２以上のキャラクタが存在し、且つ、当該２以上のキャラクタが連続したプレイ順序に配置されている場合に、ゲーム上の特殊効果を発生させる特殊効果発生手段（84）をさらに備えていることが好ましい。

ここで、第１ユーザのゲーム内グループの各キャラクタのプレイ順序を予め定めることができるゲームの例としては、チームオーダー（打順）を定めることができる野球、ソフトボール等のゲームを挙げることができる。そして、例えば、第１ユーザＡのゲーム内グループとしての野球チームにおいて、コミュニティサービスにおいて所定の関係を有している間柄の２人以上の第２ユーザＢ、Ｃ…に各々対応付けられたキャラクタが連続した打順に配置されている場合に、特殊効果が発生する。従って、第１ユーザはゲームを有利に運ぶためには、コミュニティサービスにおいて第２ユーザ同士が所定の関係を有している２以上のキャラクタを、連続したプレイ順序に配置するという戦略をとれる。本構成により、ゲームの興趣性をより高めることができる。

１０）上記の９）の構成において、前記特殊効果発生手段（84）は、前記２以上のキャラクタのプレイ順序の連続が長くなるほど、前記特殊効果をより大きくすることが好ましい。

この構成によれば、第１ユーザはゲームを有利に運ぶためには、コミュニティサービスにおいて第２ユーザ同士が所定の関係を有している２以上のキャラクタのプレイ順序（野球ゲームの場合打順）の連続をできるだけ長くするという戦略をとれる。本構成により、ゲームの興趣性をより高めることができる。

１１）上記の１）ないし１０）の何れかの構成において、前記交流度合いに基づいて、前記複数の第２ユーザの中から、前記対応付け手段（71）によって前記複数のキャラクタに対応付けられる前記第２ユーザを決定する決定手段（73）をさらに備えていることが好ましい。

本構成では、コミュニティサービスにおける第１ユーザと第２ユーザとの交流度合いが評価されて、コミュニティサービスで第１ユーザが登録している第２ユーザの中から、第１ユーザのゲーム内グループのキャラクタに対応付けられる第２ユーザが自動的に決定される。なお、この自動的な決定をデフォルトとし、第１ユーザによる任意の変更を可能としてもよい。本構成により、第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザを選択する第１ユーザの手間を省くことができる。

１２）上記の１）ないし１１）の何れかの構成において、前記コミュニティサービスにおける前記交流とは、前記第１ユーザと前記第２ユーザとの間で、ネットワークを介して、文字情報、画像情報または音声情報が、一方的にまたは相互に伝達されることであることが好ましい。

コミュニティサービスにおける交流には、前述した、通話、チャット、メッセージの送信、イラスト画像の送信等の種々の交流を含めることができる。通話やチャットは、第１ユーザと前記第２ユーザとの間で、文字情報、画像情報または音声情報が相互に伝達される一例である。また、電子メール等のメッセージの送信は、第１ユーザと前記第２ユーザとの間で、文字情報等が一方的に相手に伝達される一例である。

１３）本発明の他の一局面によるゲームシステムは、サーバ（1,2,501）と、当該サーバ（1,2,501）との間で通信を行う端末装置（3,503）とを含み、第１ユーザと、当該第１ユーザと所定の関係がある複数の第２ユーザのそれぞれとの間で交流が可能なコミュニティサービスと連携してゲームを進行させるゲームシステムであって、前記第１ユーザが利用するゲームにおける複数のキャラクタに、前記複数の第２ユーザの少なくとも一部をそれぞれ対応付ける対応付け手段（71）、前記コミュニティサービスにおける前記第１ユーザと前記第２ユーザとの間の交流度合を取得する取得手段（72）、前記交流度合いに基づいて、前記第２ユーザと対応付けられたキャラクタのパラメータを変動させる変動手段（83）、を前記サーバ（1,2,501）又は前記端末装置（3,503）のいずれか一方が備えている。

１４）本発明の他の一局面によるゲーム管理方法は、第１ユーザと、当該第１ユーザと所定の関係がある複数の第２ユーザのそれぞれとの間で交流が可能なコミュニティサービスと連携してゲームを進行させるコンピュータにおけるゲーム管理方法であって、前記コンピュータが、前記第１ユーザが利用するゲームにおける複数のキャラクタに、前記複数の第２ユーザの少なくとも一部をそれぞれ対応付ける対応付けステップと、前記コンピュータが、前記コミュニティサービスにおける前記第１ユーザと前記第２ユーザとの間の交流度合を取得する取得ステップと、前記コンピュータが、前記交流度合いに基づいて、前記第２ユーザと対応付けられたキャラクタのパラメータを変動させる変動ステップと、を含む。

１５）本発明の他の一局面によるプログラムは、コンピュータを上記の１）ないし１２）の何れかに記載のゲーム管理装置（1,2,501,503）として動作させるためのプログラムであって、前記コンピュータを前記ゲーム管理装置（1,2,501,503）が備えている各手段として機能させるためのプログラムである。

本発明によれば、第１ユーザがコミュニティサービスにおいて交流している第２ユーザとのつながりを、ゲーム内でも強めることができるゲームを提供することができる。

本発明の一実施の形態に係るゲームシステムの構成例を示す説明図である。 ＳＮＳサーバと連携するゲームシステムの構成例を示すブロック図である。 ＳＮＳ会員データベースの一例を示す説明図である。 ゲーム管理装置のハード構成の一例を示すブロック図である。 端末装置のハード構成の一例を示すブロック図である。 ユーザのゲーム内チームのスターティングメンバの一覧画面の一例を示す説明図である。 ゲーム画面の一例を示す説明図である。 ゲーム画面の一例を示す説明図である。 能力設定画面の一例を示す説明図である。 ユーザのゲーム内チームのスターティングメンバの一覧画面の他の例を示す説明図である。 ユーザのゲーム内チームのスターティングメンバの一覧画面の他の例を示す説明図である。 ゲーム管理装置の基本的な機能的構成の一例を示す機能ブロック図である。 ユーザ情報データベースの一例を示す説明図である。 ゲーム管理装置の主要な機能的構成の一例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ＳＮＳの交流情報の一例を示す説明図である。 ＳＮＳの交流と交流ポイントとの関係の一例を示す説明図である。 ＳＮＳの交流と交流ポイントとの関係の他の例を示す説明図である。 ＳＮＳの交流と交流ポイントとの関係の他の例を示す説明図である。 第１ユーザのゲーム内キャラクタに関する情報の一例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲームサーバの動作の一例を示すフローチャートである。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 交流ポイントと能力向上率との関係の一例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲームサーバの動作の他の例を示すフローチャートである。 ユーザのゲーム内チームのスターティングメンバの一覧画面の他の例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲームシステムの他の構成例を示すブロック図である。 ゲームシステムの他の構成例を示すブロック図である。 ゲームシステムの他の構成例を示すブロック図である。 ゲームシステムの他の構成例を示すブロック図である。

以下、本発明の一実施の形態に係るゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。

〔ゲームシステムの概要〕
本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図１に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク４上に設置されたゲームサーバ１と、当該ゲームサーバ１と通信可能に接続されたデータベースサーバ２と、ネットワーク４を介してゲームサーバ１と通信可能に接続できる各ユーザの端末装置３とによって構成される。

本実施の形態のネットワーク４は、インターネットに限定されるものではなく、ゲームサーバ１と各ユーザの端末装置３との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線（電話回線、移動体通信回線等）、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ等であってもよく、或いはインターネットとこれらを組み合わせたものであってもよい。

このゲームシステムの例において、本発明の一実施の形態に係るゲーム管理装置は、ゲームサーバ１およびデータベースサーバ２から構成することができる。ゲームサーバ１は、ゲームサービスを受ける各ユーザの端末装置３からのネットワーク４を介したアクセスを受け付けて、各ユーザのゲーム情報をデータベースサーバ２（記憶装置）に蓄積して管理し、各ユーザにネットワーク４を介したゲームサービスを提供する。

ゲームサーバ１によるゲームサービスの提供の形態としては、ゲーム用のプログラム（アプリケーションソフトウェア）がゲームサーバ１に実装されており、端末装置３でゲームを実行するのではなく、端末装置３でのゲーム操作入力に応じてゲームサーバ１でゲームを実行し、その実行結果を各ユーザの端末装置３に送信する形態がある。例えば、各ユーザの端末装置３に搭載されたウェブブラウザによってゲームがプレイできる、いわゆるブラウザゲームをゲームサーバ１が提供する。あるいは、ゲームサーバ１でゲームを実行した結果のゲーム映像を、例えばストリーミング形式で端末装置３に送信する、いわゆるクラウドゲーミングのサービスをゲームサーバ１が提供する。

このブラウザゲームまたはクラウドゲーミングを提供するサービス形態では、ユーザの端末装置３にゲーム専用のソフトウェアをダウンロード又はインストールする必要がなく、端末装置３をネットワーク４に接続できる環境であれば、ユーザはどこでも気軽にゲームサーバ１から提供されるゲームサービスを楽しむことができる。これはいわゆるクライアントサーバ型のゲームシステムである。

このゲームシステムでは、ゲームサーバ１が、各ユーザの端末装置３における入力操作に応じてゲーム進行のための演算処理やデータ処理を実行する。そして、ゲームサーバ１は、演算処理等の実行結果に基づいてデータベースサーバ２内の各ユーザのゲーム情報を更新するとともに、当該実行結果をユーザの端末装置３の画面に表示させるためのゲーム画面データ（ウェブページ等）を各ユーザの端末装置３に送信する。

各ユーザの端末装置３には、ユーザーエージェントとしてウェブサイト閲覧機能を有するウェブブラウザ等が搭載されており、ゲームサーバ１から送信されたウェブページ情報を端末装置３の画面に表示することができる。また、プラグインとして動作するソフトウェアが端末装置３にインストールされている場合、画面に動画を表示できる。あるいは、端末装置３は、ゲームサーバ１から送信されたストリーミング形式等の映像を再生して画面に表示する。

あるいは、ゲームサーバ１が、各ユーザのゲーム情報を管理し、ゲーム内でのユーザ間の交流等のゲームサービスをユーザに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはユーザの端末装置３側にて行われるようなゲームシステムとすることもできる。

すなわち、ゲーム実行プログラムの一部または全部をユーザの端末装置３側にダウンロードまたはインストールし、端末装置３においてもゲーム実行処理が行われるようなゲームシステムにも適用できる。例えば、ユーザの端末装置３が、インターネット通信、無線ＬＡＮ通信、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信、または有線ＬＡＮ通信などにより他のユーザの端末装置３とピア・ツー・ピア接続し、ピア・ツー・ピア型のゲームを実行することも可能である。

端末装置３としては、例えば、携帯電話端末、ＰＨＳ（Personal Handy-phone System）端末、携帯情報端末（ＰＤＡ：Personal Digital Assistant）、携帯電話と携帯情報端末とを融合させた携帯端末であるスマートフォン、パーソナルコンピュータ（以下「ＰＣ」と呼称する）、タブレット型コンピュータ、通信機能を有するゲーム装置（据置型または携帯型のゲーム装置）または双方向の通信機能を備えた多機能型テレビジョン受像機（いわゆるスマートテレビ）など、ネットワーク４経由でゲームサーバ１に接続してゲームサービスの提供を受けることができる様々な端末が適用できる。

以下の説明では、次のような構成のゲーム管理装置を例に挙げて説明する。すなわち、ゲームサーバ１が、各ユーザの端末装置３と通信し、各ユーザのゲーム情報を管理すると共に、ゲーム実行処理も行う。また、端末装置３にもゲーム実行プログラムの一部がインストールされており、ゲームサーバ１と通信しながら、端末装置３においてもゲーム実行処理が行われる。

また、本実施の形態のゲーム管理装置は、コミュニティサービスの一例としてのＳＮＳと連携するゲームを管理する。ＳＮＳでは、例えば、ユーザが交流相手として友達登録（いわゆる友達リスト登録、アドレス帳登録等）している他のユーザの各々と所定の交流が可能である。本実施の形態では、ＳＮＳの交流として、通話（インターネット電話）、メッセージの送信（テキストチャット）、イラスト画像の送信などが可能である。

例えば、本実施の形態のゲームサーバ１およびデータベースサーバ２をＳＮＳのシステムに組み込むことによって、ＳＮＳのサービスの一つとしてソーシャルゲームサービスを提供するゲームシステムとすることができる。このようにＳＮＳのプラットフォーム上で動作するゲームシステムによりゲームサービスをユーザに提供することもできるが、ゲームサーバ１およびデータベースサーバ２をＳＮＳのシステムに組み込まずに、独立したゲームシステムとして構築してもよい。

図２に示すように、ゲームサーバ１は、ＳＮＳサーバ１０１と通信可能に接続されている。このＳＮＳサーバ１０１は、ＳＮＳデータベースサーバ１０２にＳＮＳ会員情報等を格納してＳＮＳシステムの動作を制御する。このＳＮＳデータベースサーバ１０２は、会員データベースを含んでいる。図３に示すように、会員データベース（以下、会員ＤＢ）には、例えば、会員ＩＤと関係付けて、パスワード、氏名、住所、電話番号、メールアドレス、生年月日、年齢、性別、職業、趣味、プロフィール画像等のＳＮＳ会員情報（ユーザが登録したプロフィール情報）が記憶されている。図３は、会員ＩＤ＝０００００１のユーザ１人分のＳＮＳ会員情報を例示している。なお、ＳＮＳの会員ＩＤとして、電話番号またはメールアドレスが使用されることもある。

ＳＮＳにおいて、ユーザが他のユーザと通話等の交流をするためには、ユーザ自身および交流相手となる他のユーザが、ともにＳＮＳの会員に登録（前述のＳＮＳ会員情報の登録）をしていることが必要である。さらに、ユーザは、ＳＮＳでの交流相手として、他のユーザを友達登録することが必要である。

ＳＮＳの友達登録の方法としては、ユーザが手動で交流相手となる他のユーザを登録する方法と、ＳＮＳシステムの自動登録機能を利用する方法とがある。自動登録機能とは、スマートフォン等の端末装置３にユーザ（ＳＮＳ会員）が登録しているアドレス帳の情報（現実世界の知り合いの電話番号やメールアドレスの情報）を自動的にＳＮＳサーバ１０１にアップロードし、当該アドレス帳の情報を利用して、自動的に友達登録する機能である。すなわち、ＳＮＳ会員である２人のユーザの双方が、相手の電話番号またはメールアドレスを自分の端末装置３のアドレス帳に登録している場合、ＳＮＳサーバ１０１は、自動的にその相手を友達登録する。

以下、ＳＮＳにおいて、ある第１ユーザと所定の関係にある他のユーザのことを第２ユーザと称する。ここで、「所定の関係」とは、ＳＮＳにおいてユーザ間で交流可能となる関係であればよく、上述のように、第１ユーザが交流相手として第２ユーザを友達登録している関係等がこれに該当する。なお、以下の説明では、ユーザに関する一般的な説明においては、単に「ユーザ」と記載する。また、「第１ユーザ」と「第２ユーザ」とを区別して説明する必用がある場合には、両者を区別して記載する。また、「所定の関係」は、第２ユーザが第１ユーザを交流相手として登録しているような関係、または第１ユーザおよび第２ユーザの双方が互いに交流相手として登録し合っている関係であってもよい。前記「所定の関係」を、友達、フレンド、仲間等の呼称で表してもよい。

図３の会員ＤＢには、ＳＮＳにおける第１ユーザの友達情報も記憶されている。この友達情報とは、第１ユーザが交流相手として友達登録している第２ユーザの情報である。この友達情報としては、第１ユーザの会員ＩＤと関係付けられて、第１ユーザが友達登録している複数の第２ユーザの会員ＩＤが記憶される。

また、会員ＤＢには、各ユーザのＳＮＳでの交流情報（交流履歴）も記憶されている。ＳＮＳでの交流情報の詳細については後述する。

ＳＮＳと連携するゲームを管理するゲームサーバ１は、ＳＮＳサーバ１０１を介して、第１ユーザ（ＳＮＳの会員）と関係付けられている第２ユーザに関する情報を取得したり、第１ユーザと第２ユーザの各々との間の交流情報を取得したりできる。

なお、図２の例では、ゲームの管理を行うゲームサーバ１とＳＮＳの管理を行うＳＮＳサーバ１０１とが、別々のコンピュータによって構成されているが、１つのコンピュータによって、ゲームおよびＳＮＳの管理を行うように構成することも可能である。

通常、ユーザがＳＮＳ等のコミュニティサービスで通話等の交流を行う第２ユーザは、現実世界で繋がりのある間柄である。そして、本実施の形態のゲームは、ＳＮＳで第１ユーザと交流している現実世界の友達等の第２ユーザが、第１ユーザ自身のゲーム内キャラクタと対応付けられて、第１ユーザの利用するゲームに登場する。そして、本実施の形態のゲーム管理装置は、ＳＮＳにおける第１ユーザと第２ユーザとの交流度合いに基づいて、複数の第２ユーザの中から、第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザを自動的に決定する。また、本実施の形態のゲーム管理装置は、ＳＮＳにおける第１ユーザと第２ユーザとの交流度合いに基づいて、第１ユーザが利用するゲームにおいて、第２ユーザと対応付けられたキャラクタのパラメータを自動的に変動させる。以下に、これを実現する本実施の形態に係るゲーム管理装置（ゲームサーバ１等）の構成の詳細を説明する。

〔ゲーム管理装置の構成〕
上述のように本実施の形態では、ゲーム管理装置は、ゲームサーバ１およびデータベースサーバ２から構成される。図４にゲームサーバ１のハード構成の一例を示している。同図に示すように、ゲームサーバ１は、主に、ＣＰＵ（Central Processing Unit）１１と、主記憶装置としてのＲＯＭ（Read Only Memory）１２及びＲＡＭ（Random Access Memory）１３と、補助記憶装置１４と、通信制御部１５と、入出力制御部１６とを備えており、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン１７を介して相互に接続されている。なお、バスライン１７と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

ＣＰＵ１１は、システムソフトウェアやゲームプログラム等のアプリケーションソフトウェアの命令を解釈して実行し、ゲームサーバ１全体の制御を行う。ＲＯＭ１２は、ゲームサーバ１の基本的な動作制御に必要なプログラム等を記憶している。ＲＡＭ１３は、各種プログラム及びデータを記憶し、ＣＰＵ１１に対する作業領域を確保する。

補助記憶装置１４は、ゲームプログラム等のアプリケーションソフトウェアや各種データ等を格納する記憶装置である。補助記憶装置１４としては、例えばハードディスクドライブなどを用いることができる。ゲームサーバ１（コンピュータ）をゲーム管理装置として動作させるための本実施の形態のプログラムも、この補助記憶装置１４に記憶されており、当該プログラムはゲームサーバ１の起動時に補助記憶装置１４からバスライン１７を介してＲＡＭ１３へとロードされ、当該ＣＰＵ１１によって実行される。

通信制御部１５は、ネットワーク４と接続される通信インタフェース１５ａを備え、ネットワーク４を介した各ユーザの端末装置３との間の通信を制御する。また、通信制御部１５は、ＳＮＳサーバ１０１との間の通信を制御する。

入出力制御部１６は、データベースサーバ２と通信可能に接続されており、ＣＰＵ１１がデータベースサーバ２に対してデータ（レコード）の読み書きを実行するときの入出力制御を行うデータベースインタフェースである。

データベースサーバ２は、ゲームサーバ１が管理する各ユーザのゲーム情報を記憶する領域を有する記憶装置として、例えばＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成の大容量ハードディスク装置を具備する。このデータベースサーバ２は、例えば、各ユーザを一意に識別する識別情報（ユーザＩＤ）と対応付けて、各ユーザの各種ゲーム情報（ユーザ名、レベル、ゲーム内ポイント、所持アイテムなど）を記憶するリレーショナルデータベース、オブジェクトデータベース又はオブジェクト関係データベース等として構築することができる。

本実施の形態では、ゲーム管理装置がゲームサーバ１およびデータベースサーバ２から構成される例を示すが、これに限定されるものではない。例えば、ゲームサーバ１にデータベースサーバ２の機能を持たせて、ゲーム管理装置をゲームサーバ１のみで構成することもできる。また、ゲームサーバ１の有する各機能を複数のサーバに分散して持たせて、ゲームサーバ１を複数台のサーバとして構成することもできる。例えば、ユーザが端末装置３を操作してゲームサーバ１へアクセスした場合に、当該ユーザが正規のユーザかどうかを判別する認証機能を有する認証サーバを、ゲームサーバ１のメインサーバとは別に設け、メインサーバと認証サーバとでゲームサーバ１を構成してもよい。他の構成例としては、ユーザが課金対象のアイテムをゲーム内で購入した場合に課金管理を行う課金管理サーバを、ゲームサーバ１のメインサーバ等とは別に設け、メインサーバ、認証サーバおよび課金管理サーバによりゲームサーバ１を構成してもよい。また、上述のように、１つのコンピュータによって、ゲームおよびＳＮＳの管理を行うように構成してもよく、この場合、ゲームサーバ１がＳＮＳサーバとしての機能を併せ持つことになる。

また、本ゲームサービスを利用するユーザ数が数十万人、数百万人、あるいはそれ以上となると、多数のユーザの端末装置３からの巨大なアクセスにも耐え得るサーバシステムの構築が求められるため、ネットワーク４上に複数のゲームサーバ１を設けて冗長化（多重化）を図ることにより、負荷分散型のシステム構成としてもよい。この場合、複数のゲームサーバ１間の負荷を調整するためのロードバランサを設けることが望ましい。

次に、本実施の形態に係るゲームサーバ１にアクセスしてゲームサービスの提供を受けるユーザの端末装置３の構成を説明する。

〔端末装置の構成〕
ユーザが操作する端末装置３としては、上述のようにスマートフォン、携帯電話、ＰＣをはじめとして様々な端末を適用できるが、本実施の形態では、スマートフォン等の携帯端末を例示してその構成を説明する。なお、携帯端末以外の端末装置３についても、ゲーム画面を表示したり、ゲームを実行するための入力操作を行ったりといった、ゲームをプレイする上で必要となる基本的な構成は、携帯端末と同様である。

図５に、端末装置３の構成例を示している。同図に示すように、端末装置３は、主に、ＣＰＵ３１と、主記憶装置としてのＲＯＭ３２及びＲＡＭ３３と、画像処理部３４と、表示部３５と、サウンド処理部３６と、音声入力部３７と、音声出力部３８と、補助記憶装置３９と、操作入力部４０と、通信制御部４１とを備えており、構成要素３１〜３４、３６および３９〜４１はバスライン４２を介して相互に接続されている。なお、バスライン４２と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

ＣＰＵ３１は、ゲーム実行プログラムやウェブブラウザを含む各種プログラムの命令を解釈して実行し、端末装置３全体の制御を行う。ＲＯＭ３２には、端末装置３の基本的な動作制御に必要なプログラム等が記憶されている。また、ＲＡＭ３３には、ＲＯＭ３２または補助記憶装置３９からロードされた各種プログラムやデータが記憶され、ＣＰＵ３１に対する作業領域を確保する。ゲーム実行プログラム、ウェブブラウザ等の各種プログラムは、ＲＯＭ３２または補助記憶装置３９に記憶されており、ＲＡＭ３３にロードされてＣＰＵ３１によって実行される。また、ウェブブラウザを使用して画面を表示させる場合、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインソフトウェアを、ウェブブラウザと共にＲＯＭ３２または補助記憶装置３９に記憶していてもよい。

画像処理部３４は、ＣＰＵ３１からの画像表示命令に基づいて表示部３５を駆動し、当該表示部３５の画面に画像を表示させる。表示部３５には、液晶ディスプレイまたは有機ＥＬ（Electro-Luminescence）ディスプレイ等の既知の種々の表示装置が適用できる。

サウンド処理部３６は、音声入力部３７から音声が入力されたときにアナログ音声信号をデジタル音声信号に変換するとともに、ＣＰＵ３１からの発音指示に基づいてアナログ音声信号を生成して音声出力部３８に出力する。音声入力部３７は、端末装置３に内蔵されたマイクロフォンからなり、電話通信する場合や録音を行う場合などに用いられる。音声出力部３８は、電話通信時の受話スピーカおよび電話着信音やゲーム実行時の効果音などを出力するスピーカからなる。

補助記憶装置３９は、前述の各種プログラムやデータ等を格納する記憶装置である。補助記憶装置３９としては、例えばハードディスクドライブ、フラッシュメモリドライブ、メモリカードリーダライタ等を用いることができる。

操作入力部４０は、ユーザの操作入力を受け入れて当該操作入力に対応した入力信号を、バスライン４２を介してＣＰＵ３１に出力するものである。操作入力部４０の例としては、端末装置３の本体に設けられた方向指示ボタン、決定ボタン、英数文字等入力ボタンなどの物理的ボタンがある。また、表示部３５の画面にタッチパネル（接触入力式のインタフェース）を搭載することによって表示部３５をいわゆるタッチスクリーンとして構成している端末装置３の場合、当該タッチパネルも操作入力部４０となる。

また、一般的な音声認識技術を利用して、音声入力部３７から入力された音声をＣＰＵ３１が解析し、各種入力を、音声により行うことができる構成としてもよい。

通信制御部４１は、通信インタフェース４１ａを備え、ゲーム操作時等にデータ通信するための通信制御機能および電話端末として音声データを送受信するための通信制御機能等を有している。ここで、データ通信用の通信制御機能には、例えば、無線ＬＡＮ接続機能、無線ＬＡＮや携帯電話回線網を介したインターネット接続機能、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信機能などが含まれる。通信制御部４１は、ＣＰＵ３１からの命令に基づいて端末装置３を無線ＬＡＮやインターネット等に接続するための接続信号を発信するとともに、通信相手側から送信されてきた情報を受信してＣＰＵ３１へ供給する。

なお、端末装置３には、その他にもＧＰＳ（Global Positioning System）信号受信回路、ＣＣＤ（Charge Coupled Device）イメージセンサ等の撮像装置（カメラ）、３軸加速度センサなどが備えられていてもよく、例えば、ＧＰＳ位置情報などをゲーム内で活用してもよい。

上記構成の端末装置３において、ゲームサービスを受けようとするユーザは、ゲームプログラム（またはウェブブラウザ）を立ち上げてゲームサーバ１が管理するゲームサイトにアクセスする入力操作を行う。このアクセスがゲームサーバ１に認証された場合、端末装置３の通信制御部４１がゲームサーバ１から送信されてくるゲーム画面データ（ＨＴＭＬ等で記述されたデータ）を受信し、ＣＰＵ３１がゲームプログラム（またはウェブブラウザ）を実行してゲーム画面を表示部３５に表示させる。ここでユーザは、ゲーム画面に表示されている選択可能なボタンオブジェクトやハイパーリンクを、操作入力部４０を操作して選択入力する。この選択入力に応じてゲームサーバ１が必要なデータ処理を実行し、新たなゲーム画面データを端末装置３に送信する。そして、この新たなゲーム画面が端末装置３の表示部３５に表示され、以下、同様に、ユーザは、表示部３５に表示されているゲーム画面で選択可能なボタンオブジェクト等を選択する操作により、ゲームサーバ１が提供するサービスを受けることができるようになっている。

〔ゲームの説明〕
上述のように、本実施の形態のゲームは、コミュニティサービスの一例であるＳＮＳと連携し、第１ユーザのゲーム内グループのキャラクタに、ＳＮＳで第１ユーザが友達登録している第２ユーザを対応付けることができるゲームである。

ゲームとゲーム外サービスであるＳＮＳとの連携を図るため、ゲーム内で各ユーザを一意に識別するためのユーザＩＤと、ＳＮＳでユーザを一意に識別するための会員ＩＤとは、共通とすることが好ましい。例えば、ユーザが先ずＳＮＳの会員に登録し、ＳＮＳ経由でゲームに登録する場合、ＳＮＳの会員ＩＤをそのままゲームのユーザＩＤとすることが可能である。ＳＮＳ経由でユーザがゲームに登録する場合、当該ユーザのＳＮＳ会員ＩＤが、ＳＮＳサーバ１０１からゲームサーバ１に通知される。

また、ゲームのユーザＩＤとＳＮＳの会員ＩＤとを異なるものとすることもできる。この場合、ゲームとＳＮＳとの連携を図るため、ゲームのユーザＩＤとＳＮＳの会員ＩＤとを関係付ける関係情報を、記憶装置（データベースサーバ２等）に記憶し、関係情報に基づいてユーザＩＤと会員ＩＤとの整合を図ればよい。この場合、ユーザがＳＮＳ経由でゲームに登録することもできるし、ゲームに登録後にＳＮＳに登録することもできる。ＳＮＳ経由でユーザがゲームに登録する場合、当該ユーザのＳＮＳ会員ＩＤが、ＳＮＳサーバ１０１からゲームサーバ１に通知されるので、ゲームサーバ１は、通知されたＳＮＳの会員ＩＤとゲームのユーザＩＤとを関係づける。また、ユーザがゲームに登録後にＳＮＳに登録した場合、例えば、ゲーム内に設けられた入力画面で、ユーザが自分のＳＮＳ会員ＩＤを入力できるようにする。このＳＮＳ会員ＩＤの入力に応じて、ゲームサーバ１は、ゲームのユーザＩＤとＳＮＳの会員ＩＤとを関係づける。

ゲーム管理装置によって管理されるゲームの例としては、野球、サッカー、テニス、アメリカンフットボール、バスケットボール、バレーボール、カーレースなどを題材としたスポーツ・レースゲーム、アクションゲーム、シミュレーションゲーム、育成ゲーム、ロールプレイングゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、主に、ゲーム管理装置が自分のゲーム内グループのキャラクタを使用して野球を楽しむ野球ゲームを管理する例について、以下に説明する。

本実施の形態の野球ゲームは、ゲーム外サービスであるＳＮＳと連携し、ＳＮＳで第１ユーザが友達登録している第２ユーザ（すなわち、ＳＮＳで第１ユーザと交流している現実世界の友達）が、第１ユーザの野球チームのキャラクタと対応付けられて、第１ユーザがプレイするゲームに登場する。

以下、第１ユーザのゲーム内野球チームにおいて、第２ユーザと対応付けられたキャラクタのことを、単に「第２ユーザのキャラクタ」と称するものとする。

本ゲームでは、第１ユーザの野球チームには、第２ユーザの名前（またはニックネーム、あるいはアバター画像等）が対応付けられたキャラクタが所属することになる。換言すれば、第２ユーザのキャラクタが、ゲーム内で仮想的に第１ユーザのチームメイトとなる。そして、第１ユーザは、第２ユーザのキャラクタを含む自分のチームのキャラクタを使用してバッティング等の操作を行い、ゲーム内で仮想的に野球を楽しむことができる。

図６に、第１ユーザＡの端末装置３に表示されるゲーム画面の一例を示す。図６の画面は、第１ユーザＡが端末装置３で野球ゲームの開始ボタンを押した直後に表示される、第１ユーザＡの野球チームのスターティングメンバ（以下、スタメンと称する）の一覧画面である。第１ユーザＡの野球チームのスタメンには、打順が１番から９番の打者９人および先発投手１人の合計１０人のキャラクタが含まれる。そのうちの１人のキャラクタは、第１ユーザＡ自身の分身的なキャラクタ（以下、「マイキャラクタ」と称する）である。また、マイキャラクタ以外のスタメンのキャラクタは、基本的に、第２ユーザのキャラクタである。図６では、１番打者が第１ユーザＡのマイキャラクタであり、その他が第２ユーザのキャラクタである例を示している。なお、スタメンのキャラクタに対応付けられなかった第２ユーザについては、第１ユーザＡの野球チームの控え（ベンチ入り）のキャラクタに対応付けられるものとしてもよい。

本ゲームサーバ１は、ＳＮＳにおける第１ユーザと第２ユーザの各々との交流度合いを評価し、複数の第２ユーザの中から、第１ユーザのチームのスタメンのキャラクタに対応付けられる第２ユーザを自動的に決定する機能を有する。例えば、所定期間（過去１か月、１週間等）のＳＮＳでの交流度合い（交流回数、頻度等の交流の程度）を評価し、評価の高い上位９人の第２ユーザを選択する。例えば、ゲームサーバ１は、ＳＮＳでの交流の内容に応じて交流ポイントを付与し、第１ユーザと第２ユーザの各々との交流度合いを評価する。交流ポイントの具体例としては、通話：１０ポイント／回、メッセージの送信：５ポイント／回、イラスト画像の送信：２ポイント／回、等である。ＳＮＳにおける第１ユーザと第２ユーザの各々との交流度合いの詳細については、後述する。また、ＳＮＳの交流度合いに基づいて、キャラクタに対応付けられる第２ユーザを選択する種々のバリエーションについても、後述する。

図６の画面において、スタメンの各キャラクタの表示欄には、キャラクタの画像２０１、キャラクタ名（キャラクタに対応付けられているユーザ名）２０２、ポジション２０３、調子マーク２０４、ロックボタン２０５等が表示される。ここで、調子マーク２０４は、キャラクタの調子の良さ（または体調の良さ）を表示する画像である。本実施の形態では、０〜４の５段階の調子パラメータ（０＝絶不調、１＝不調、２＝普通、３＝好調、４＝絶好調）の何れかが、各キャラクタに設定される。そして、各キャラクタの調子パラメータに対応した調子マーク２０４が画面に表示される。例えば、第１ユーザのマイキャラクタの調子パラメータは、その日、最初にゲームにアクセスしたときにランダムに決定される。また、例えば、第２ユーザのキャラクタの調子パラメータは、スタメン決定時等に、ランダムに決定される。

調子パラメータによって、キャラクタの能力が変化する。例えば、調子パラメータが、０、１、２、３、４の場合、キャラクタの能力はそれぞれ、−５％、−３％、±０％、＋３％、＋５％となる。

また、ゲームサーバ１は、ＳＮＳにおける第１ユーザと第２ユーザの各々との交流度合いに基づいて、第２ユーザのキャラクタの打順（チーム内の役割）を自動的に決定する機能も有する。例えば、交流度合いが大きい第２ユーザのキャラクタは、クリーンナップ（３番〜５番）または上位打線に自動的に設定される。この場合、一旦、クリーンナップに自動設定された第２ユーザのキャラクタであっても、第１ユーザと第２ユーザとの現実世界での交流（ＳＮＳでの交流）が少なくなると、その第２ユーザのキャラクタの打順は、自動的に下位打線に変更される。なお、第１ユーザのマイキャラクタは、所定の打順（例えば１番、４番等）に設定されるようにしてもよい。

また、ゲームサーバ１は、第１ユーザの第２ユーザがＳＮＳにおいて登録している年齢、性別、趣味等のプロフィール情報を、ＳＮＳサーバ１０１から取得し、前記プロフィール情報に基づいて、第２ユーザのキャラクタの打順を調整してもよい。例えば、女性、子供（所定以下の年齢）、高齢者（所定以上の年齢）の第２ユーザのキャラクタについては、交流度合いに基づいて決定した打順から、下位側に打順を下げたり、スタメンから外したりしてもよい。その詳細については後述する。

本実施の形態の場合、一旦、スタメンとして選ばれた第２ユーザのキャラクタであっても、ＳＮＳでの第１ユーザとの交流度合いが低下すれば、スタメンから外れることがある。また、第２ユーザのキャラクタの打順も、ＳＮＳでの第１ユーザと第２ユーザとの交流度合いの変化に応じて、自動的に変更される。但し、第１ユーザにとっては、特定の第２ユーザのキャラクタを、常にスタメンに入れておきたいと思うこともある。また、特定の第２ユーザのキャラクタの打順を固定したいと思うこともある。そこで、図６に示すように、特定の第２ユーザのキャラクタをスタメンに固定する（および現在の打順に固定する）ためのロックボタン２０５が設けられている。スタメン一覧画面で、第１ユーザがロックボタン２０５を選択する操作をすれば、選択されたロックボタン２０５に対応する第２ユーザのキャラクタは、その後、常に、スタメンに登場する。また、ロックボタン２０５が押された第２ユーザのキャラクタは、その後、常に、現在の打順に固定されるようにしてもよい。

なお、上記のようなスタメンの自動決定をデフォルトとし、第１ユーザの操作による任意の変更を可能としてもよい。すなわち、スタメンのキャラクタに対応付けられなかった第２ユーザを、第１ユーザが手動で、スタメンのキャラクタに対応付けることができるようにする（スタメンのキャラクタに対応付ける第２ユーザの入れ替えを可能とする）。また、キャラクタの打順も、第１ユーザの操作により、任意に変更可能としてもよい。

上記では、ゲームサーバ１が、ＳＮＳにおける第１ユーザと第２ユーザの各々との交流を評価し、スタメンのキャラクタに対応付けられる第２ユーザを自動決定する好ましい形態について説明したが、これに限定されない。例えば、ゲームサーバ１がスタメンを自動決定する場合、複数の第２ユーザの中からランダムに（すなわち、ＳＮＳの交流度合いに基づかないで）、スタメンのキャラクタに対応付けられる第２ユーザを選択するようにしてもよい。また、スタメンを自動決定することなく、第１ユーザが手動で、スタメンのキャラクタに対応付けられる第２ユーザを選択するようにしてもよい。

また、第２ユーザが第１ユーザのスタメン（あるいはクリーンナップ）のキャラクタに対応付けられた場合に、その旨が第２ユーザに自動的に通知されるようにすることが好ましい。その詳細については後述する。

図６の画面において、第１ユーザがプレイボタン２１０を選択すれば、野球ゲームが開始される。この野球ゲームの一例としては、攻撃イニングと守備イニングを交互に繰り返す一般的な野球ルールに従ったゲーム形式とすることができる。あるいは、攻撃のみに特化したゲーム形式としたり、逆に守備のみに特化したゲーム形式としたりしてもよい。あるいは、ホームラン競争ゲームとすることもできる。これらは一例であり、ゲーム内容については特に限定されるものではない。

本実施の形態では、手軽な操作で野球を体験できるように、１イニングの攻撃のみに特化したゲーム形式を採用した例について説明する。図６の画面でプレイボタン２１０が選択された場合、図７に例示するバッティング操作画面に遷移する。この画面で、第１ユーザは、図６の打順に従ってスタメンのキャラクタを順次使用して、バッティングの操作を行う。第１ユーザは、スリーアウトになるまでプレイを続けることができ、スリーアウトになった時点で、１ゲームが終了となる。

図７の画面には、第１ユーザのチームのスタメンの一人である打者キャラクタ３０１と、投手キャラクタ３０２とが表示される。また、ホームベース３０３の付近にはミートカーソル３０４が表示される。このミートカーソル３０４は、投手キャラクタ３０２が投げたボールオブジェクトに、バット３０５を当てる目安として設けられたものである。第１ユーザは、投手キャラクタ３０２が投球したボールオブジェクトに対して、ミートカーソル３０４を重ね合わせ、且つ、ホームベース３０３の近傍をボールオブジェクトが通過するタイミングでバットスイング（打撃）操作をすることで、ボールオブジェクトを打ち返すことができる。

なお、ミートカーソル３０４の大きさは、打者キャラクタ３０１のミートの能力に応じて変化する。具体的には、端末装置３のＣＰＵ３１は、打者キャラクタ３０１のミートの能力が高いほどミートカーソル３０４のサイズを大きく設定する。キャラクタの能力については後述する。

本実施の形態の端末装置３の表示部３５はタッチパネルとなっており、第１ユーザは指またはペン等を画面に接触させて、ミートカーソル３０４の移動操作を行うことができる。ここで、第１ユーザがミートカーソル３０４に、直接、指を重ねてその移動操作を行う場合、ボールオブジェクトやミートカーソル３０４が、部分的に第１ユーザ自身の指で隠れてしまい、操作性に支障を来すことになる。そこで、本実施の形態では、ミートカーソル３０４とは異なる画面上の位置に、ミートカーソル３０４の移動操作を行うための操作アイコン３０６が表示されるようになっている。ミートカーソル３０４は、操作アイコン３０６との間の相対的な位置関係を維持したまま、操作アイコン３０６の変位に連動して移動する。操作アイコン３０６の移動操作は、画面上の操作アイコン３０６に指３２０を接触させた状態で、画面から指３２０を離さずにドラッグすることにより可能である。よって、第１ユーザは、指３２０をミートカーソル３０４に直接的に接触させることなく、異なる領域に表示されている操作アイコン３０６に指３２０を接触させてドラッグすることで、それに連動するミートカーソル３０４を間接的に移動させることができる。

投手キャラクタ３０２が投げたボールオブジェクトは、ホームベース３０３側に近づいてくる。第１ユーザは、ボールオブジェクトがベース上に到着するタイミングを見計らいながら、画面上の操作アイコン３０６に接触させている指３２０を、画面から離す。図８に示すように、第１ユーザが指３２０を画面から離したことを契機として、打者キャラクタ３０１のバットスイングが行なわれる。すなわち、本ゲームのバットスイング操作は、指３２０を画面から離すことである。このように、本構成においては、ミートカーソル３０４の移動操作とバットスイング操作の両方を、１本の指３２０のドラッグおよびドロップによって円滑に行うことができる。しかも、ミートカーソル３０４およびボールオブジェクトの表示が、指３２０によって遮られることもないので、画面の視認性にも優れた高い操作性を実現している。

なお、図７では、ミートカーソル３０４の移動操作を行うための操作アイコン３０６を画面の右側に配置した例を示したが、これに限定されない。すなわち、操作アイコン３０６は、画面上で、ミートカーソル３０４とは異なる任意の位置に存在すればよい。よって、例えば、操作アイコン３０６を、ミートカーソル３０４よりも左側に配置してもよいし、投手キャラクタ３０２よりも上方に配置してもよい。

また、次のようにすることにより、操作アイコン３０６を用いることなく、上記と同様のミートカーソル３０４の移動操作が可能である。すなわち、第１ユーザが画面上の任意の位置（ミートカーソル３０４とは異なる位置）に指３２０を接触させる。この場合、端末装置３は、指３２０が画面に接触している位置座標を取得し、その後は、指３２０が画面上を移動しても、指３２０の接触位置と、ミートカーソル３０４の位置との間の相対的な位置関係を維持する。よって、第１ユーザが指３２０を画面に接触させたまま移動（すなわちドラッグ）すれば、ミートカーソル３０４は、指３２０の接触位置との間の相対的な位置関係を維持したまま、操作アイコン３０６の変位に連動して移動する。この場合も、第１ユーザが指３２０を画面から離したことを契機として、バットスイングが行われる。

上記のようにして第１ユーザが打撃操作をした場合、端末装置３は、打撃判定を行う。例えば、ボールオブジェクトにミートカーソル３０４が重なっていない状態でバットスイング操作をすれば、空振りとなる。また、バットスイング操作のタイミングが打撃可能範囲からずれていた場合も、空振りとなる。一方、ボールオブジェクトに対して、ミートカーソル３０４の少なくとも一部が重なり、且つ、バットスイング操作のタイミングが打撃可能範囲であった場合には、ボールオブジェクトが打ち返される。この場合、端末装置３は、ボールオブジェクトの中心とミートカーソル３０４の中心との間の距離、およびバットスイング操作のタイミングに基づいて、打球の方向、初速度等を演算し、ボールオブジェクトの軌道を決定する。そして、端末装置３は、ゲーム空間内において、決定した軌道にしたがってボールオブジェクトを移動させる。さらに、端末装置３は、打撃後のボールオブジェクトの軌道により、打撃結果（シングルヒット、二塁打、三塁打、本塁打、アウト等）を決定し、画面に表示する。

本ゲームでは、打撃結果に応じて、第１ユーザにポイントが付与される。例えば、シングルヒット：１０ポイント、二塁打：２０ポイント、三塁打：３０ポイント、本塁打：４０ポイント、１打点につき５０ポイント、等である。第１ユーザが獲得したポイントは、図７および図８のゲーム画面の獲得ポイント表示領域３０７に表示される。

第１ユーザは、スタメンのキャラクタを順次使用して上記のバッティング操作を行う。その後、スリーアウトになった時点で、図９の能力設定画面に遷移する。この画面には、スリーアウトになるまでに獲得したポイントの表示領域３１１が設けられている。第１ユーザが獲得したポイントは、第１ユーザのマイキャラクタの能力パラメータを向上させることができる能力向上用ポイントである。本実施の形態では、キャラクタのパラメータとして、パワー、ミート、弾道、走力、肩力、守備力の各能力が設けられている。なお、パワー、ミート、弾道、走力のパラメータは、主に、攻撃を含むゲームモードにおいて使用される。また、走力、肩力、守備力のパラメータは、主に、守備を含むゲームモードにおいて使用される。

また、各能力には、Ｓ（最高ランク）、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ（最低ランク）の８つのランクが設けられている。ゲームに登録した直後は、各能力ともＧランクからスタートする。同じランクでも、ランク内のポイントが大きいほど能力は高くなる。例えば、Ｇランクは「Ｇ１」から「Ｇ２９」まであり、「Ｇ１」よりも「Ｇ２９」の方が能力は高い。「Ｇ３０」＝「Ｆ１」であり、Ｇランクで３０ポイント獲得すれば、Ｆランクにランクアップする。このように、能力のランクアップには所定のポイントが必要である。能力のランクが向上するほど、ランクアップに必要なポイントも大きくなる。例えば、ＧランクからＦランクにランクアップするには、３０ポイントが必要であるが、ＦランクからＥランクにランクアップするには、５０ポイントが必要である。また、例えば、ＡランクからＳランクにランクアップするには、５００ポイント必要である。

なお、前記「Ｇ１」を能力値で表すと「１」であり、前記「Ｆ１」を能力値で表すと「３０」である。このように、各ランクの能力を数値として管理してもよい。

第１ユーザは、ゲームにより獲得したポイントを、任意の能力に割り振って、能力の向上を図ることができる。例えば、第１ユーザがゲームで８５ポイントを獲得したのであれば、パワーに２０ポイント、ミートに３０ポイント、走力に１５ポイントというように、向上させたい能力を選択して、ポイントを任意に割り振ることができる。例えば、ミートの能力を向上させる場合、画面上のミートの表示領域３１２を選択すれば、図示しないポイント指定ウインドウが開き、ミートに割り振るポイントを指定できる。

図９の能力設定画面において、第１ユーザは、マイキャラクタの能力を向上させた後、再度、前述のゲームを遊戯することができる。このように、ゲームでポイントを獲得し、獲得したポイントでキャラクタの能力向上を図るというゲームサイクルで、キャラクタを成長させながらゲームを楽しむことができる。

なお、第１ユーザがゲームを遊戯するためには、「体力」というポイントを必要とするようにしてもよい。例えば、ゲームを１回遊戯することにより、「体力」を１ポイント消費する。この体力は、第１ユーザが所有しているポイントであり、ゲーム中に消費されて減った体力は、時間の経過により回復（例えば、８分経過毎に１ポイントずつ回復）する。また、第１ユーザのレベルアップ時または回復アイテムの使用により、消費されて減った体力が一気に回復するようにしてもよい。第１ユーザが所有できる体力の最大値は、第１ユーザのゲームのレベルが向上する毎に増えて行く。第１ユーザのレベルは、ゲーム経験の豊富さ、ゲームの習熟度の高さの指標となるものである。本実施の形態では、第１ユーザが前記野球ゲームを遊戯することにより経験値が蓄積され、当該経験値が一定量に達することによりレベルアップするようになっている。

第１ユーザのチームのスタメンのうち、マイキャラクタのパラメータについては、上記のようにして第１ユーザが向上させた能力が適用される。また、第１ユーザのチームのスタメンのうち、第２ユーザのキャラクタの能力をどのように設定するかについては、以下のような様々なバリエーションが考えられる。

例えば、第１ユーザのチーム内の全ての第２ユーザのキャラクタの能力（基本パラメータ）を、同一とする。具体例を挙げると、全ての第２ユーザのキャラクタのパワー等の能力を、Ｆランク（例えば「Ｆ１」）にする。あるいは、第２ユーザのキャラクタの各々の能力がランダムに決定されるようにしてもよい。例えば、チーム内の第２ユーザのキャラクタの各々には、Ｅランク、Ｆランク、Ｇランクの中からランダムに選ばれたランクの能力が設定されるようにする。あるいは、後述するように、第１ユーザのチーム内の役割である打順に応じて、第２ユーザのキャラクタの能力を異ならせてもよい。

なお、上述のように、第１ユーザは、ゲームを遊戯することによってマイキャラクタの能力を向上させることができる。そして、第１ユーザが次にゲームを遊戯する場合には、向上させたマイキャラクタの能力（パラメータ）が適用される。これに対して、第１ユーザのチーム内の各第２ユーザのキャラクタの能力については、基本的に、第１ユーザがゲームを遊戯する都度、毎回、新たに設定されるようにすることができる。但し、これに限定されるものではなく、第１ユーザによる第２ユーザのキャラクタを使用したゲーム結果によって、第２ユーザのキャラクタのパラメータが変動（向上または低下）するようにし、第２ユーザのキャラクタの能力が次回のゲームにも持ち越されるようにしてもよい。例えば、第１ユーザが第２ユーザのキャラクタを使用してシングルヒットを打てば第２ユーザのキャラクタの能力が「＋１０」となり、二塁打なら「＋２０」、三塁打なら「＋３０」、本塁打なら「＋４０」となるようにする。また、三振すれば前記能力が低下する（例えば「−５」）ようにしてもよい。この場合、ゲームサーバ１は、第１ユーザのユーザＩＤと関係付けて、マイキャラクタと同様に、第１ユーザのチーム内の各第２ユーザのキャラクタのパラメータもデータベースサーバ２に記憶して管理し、次回のゲームで同じ第２ユーザのキャラクタが使用される場合に、データベースサーバ２から第２ユーザのパラメータの情報を読み出して能力等の設定を行えばよい。

また、各ユーザは、ＳＮＳで友達関係にある他のユーザにアピールできるように、自分の分身的なマイキャラクタの容姿を任意に設定することができるようにしてもよい。この場合、図６の第１ユーザのチームのスタメンのうち、ゲームに登録済みの第２ユーザのキャラクタの容姿については、当該第２ユーザが自ら設定したマイキャラクタの容姿が適用される。一方、第１ユーザのチームのスタメンのうち、ゲームに未登録の第２ユーザのキャラクタについては、汎用キャラクタが適用される。この汎用キャラクタの容姿は、ゲームサーバ１が決定する。例えば、ゲームサーバ１は、複数のキャラクタの容姿の中から任意の容姿を選択して、ゲームに未登録の第２ユーザの汎用キャラクタの容姿とする。この場合、第１ユーザの第２ユーザがＳＮＳにおいて登録している性別、年齢等のプロフィール情報に基づいて、汎用キャラクタの容姿を決定してもよい。例えば、第２ユーザが女性ならば、女性の容姿の汎用キャラクタが適用される。

また、図１０に示すように、第１ユーザのチームのスタメン一覧画面には、ゲームに未登録の第２ユーザをゲームに招待するための招待ボタン２０６（招待操作部）を表示してもよい。なお、図１０の画面では、便宜上、前述のロックボタン２０５（図６参照）を省略しているが、ロックボタン２０５を設けてもよい。第１ユーザは、ゲームに招待したい第２ユーザの招待ボタン２０６を押すだけで、簡単に、その第２ユーザをゲームに招待することができる。そして、第１ユーザがゲームに招待した第２ユーザのキャラクタのパラメータ（能力）が、一時的に向上する。例えば、図１０の画面において、８番打者の第２ユーザＨの招待ボタン２０６が押された場合、図１１に例示するように、「能力ＵＰ 招待済」というラベル２０８が表示され、ゲームへの招待により第２ユーザＨのキャラクタの能力が向上した旨が報知される。なお、図１０の画面と図１１の画面との間に、第２ユーザＨをゲームへ招待することについての確認画面が挿入されてもよい。本構成により、第１ユーザに対して、ゲームに未登録の第２ユーザを積極的にゲームに招待するように動機付けることができる。

また、図１０に示すように、第１ユーザのチームのスタメン一覧画面には、ゲームに登録済みの第２ユーザに対して、ゲーム内交流としての挨拶を行うための挨拶ボタン２０７（ゲーム内交流操作部）を表示してもよい。ここで、挨拶とは、ゲーム内で仮想的に行うことができる簡易的な交流の総称であり、応援する、エールを送る、ウインクする、微笑む、手を振る、足跡を残すなど、別の表現を用いた簡易的な交流も含まれる。挨拶を受けた側の第２ユーザは、自分の端末装置３の画面で、いつ誰が挨拶してくれたかという交流に関する情報を確認することができる。図１０の画面において、第１ユーザは、挨拶したい第２ユーザの挨拶ボタン２０７を押すだけで、簡単に、その第２ユーザに挨拶をすることができる。そして、第１ユーザが挨拶した第２ユーザのキャラクタのパラメータ（能力）が、一時的に向上する。例えば、図１０の画面において、４番打者の第２ユーザＤの挨拶ボタン２０７が押された場合、図１１に例示するように、「能力ＵＰ 挨拶済」というラベル２０９が表示され、第１ユーザが挨拶した第２ユーザＤのキャラクタの能力が向上した旨が報知される。本構成により、第１ユーザに対して、ゲームに登録済みの第２ユーザと積極的にゲーム内交流をするように動機付けることができる。

また、本ゲームの好ましい態様としては、ＳＮＳにおける第１ユーザと第２ユーザの各々との間の交流度合いに基づいて、第１ユーザのゲーム内のチームに所属する各第２ユーザのキャラクタのパラメータ（能力）が変動する。このパラメータの変動は、一時的（例えば、１回のプレイのみ、１日だけ等）であるようにして、その後、変動前のパラメータに戻る。あるいは、一度変動したパラメータは、元に戻らないようにしてもよい。

例えば、ゲームサーバ１は、前述のように、ＳＮＳでの交流の内容に応じて交流ポイントを付与する（通話：１０ポイント／回、メッセージの送信：５ポイント／回、イラスト画像の送信：２ポイント／回、等）。そして、例えば、１日の交流ポイントの合計が大きい第２ユーザのキャラクタほど、能力の向上率を高くする。具体例を挙げると、図２９に示すように、１日の交流ポイントの合計が「２〜４」の第２ユーザのキャラクタの能力を５％向上させる。また、１日の交流ポイントの合計が「５〜７」で７％、「８〜９」で９％、「１０〜１５」で１０％、「１６〜２０」で１５％、「２１以上」で２０％、第２ユーザのキャラクタの能力をそれぞれ向上させる。

ここで、パラメータ変動の対象となる第２ユーザのキャラクタの基本能力（変動前の基本パラメータ）については、様々なバリエーションが考えられる。前述のように、第１ユーザのチーム内の全ての第２ユーザのキャラクタの能力を同一としたり、ゲームに登録済みの第２ユーザのキャラクタの能力を当該第２ユーザ自身のマイキャラクタの能力としたりできる。あるいは、第１ユーザのチーム内の役割である打順に応じて、第２ユーザのキャラクタの基本能力を異ならせてもよい。例えば、第１ユーザのチームのクリーンナップ（打順の３番、４番、５番）のキャラクタについては、その基本能力を、他の打順のキャラクタよりも大きく設定しておく。

この場合、クリーンナップのキャラクタは、高い基本パラメータをベースとすることになるので、実質的に、他のキャラクタよりも高いパラメータの向上を見込めることになる。従って、第１ユーザは、ゲームを有利に運ぶためには、特に、クリーンナップのキャラクタに対応付けられた第２ユーザと、ＳＮＳでより多くの交流を行うといった戦略をとれる。あるいは逆に、普段からＳＮＳでの交流が多い第２ユーザをクリーンナップのキャラクタに対応付けるようにしてもよい。

また、第２ユーザがＳＮＳにおいて登録している年齢、性別、趣味等のプロフィール情報に基づいて、第１ユーザのチーム内の第２ユーザのキャラクタの基本パラメータを調整してもよい。例えば、女性、子供（所定以下の年齢）、高齢者（所定以上の年齢）の第２ユーザのキャラクタについては、基本パラメータのパワーの値を本来の値よりも低下させる一方、ミートの値を本来の値よりも向上させる。これにより、ボールには当て易いが、長打にはなり難いようにする。その詳細については後述する。

また、第１ユーザのチームのキャラクタに対応付けられた第２ユーザの中に、ＳＮＳにおいて第２ユーザ同士が所定の関係を有している（例えば、第２ユーザ同士が交流相手として相手を登録している）２人以上の第２ユーザが存在する場合に、第１ユーザのゲームにおいて特殊効果が発生するようにしてもよい。例えば、第１ユーザＡのチームのキャラクタに、第２ユーザＢ、Ｃ、Ｄ…が対応付けられているものとする。そして、ＳＮＳにおいて、第２ユーザＢおよび第２ユーザＣが互いを交流相手として登録している場合、第１ユーザＡのゲームにおいて、ゲーム上の特殊効果が発生する。例えば、第２ユーザＢ、Ｃのキャラクタの能力が一時的に向上する。その詳細については後述する。

〔ゲーム管理装置の機能的構成および動作〕
次に、上記のゲームを実現するゲーム管理装置の機能的構成の一例について説明する。

図１２は、端末装置３と通信するゲーム管理装置（ゲームサーバ１およびデータベースサーバ２）の基本的な構成を示す機能ブロック図である。

本実施の形態に係るゲーム管理装置は、ユーザ情報記憶制御手段６０、受信手段６１、実行手段６２、画面生成手段６３、送信手段６４、アクセス管理手段６５および交流制御手段６６等を備えている。これらの各手段は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

ユーザ情報記憶制御手段６０は、ゲームに登録済みのユーザ（第１ユーザまたは第２ユーザ）のゲームに関する情報を、データベースサーバ２に記憶して管理する。ユーザ情報記憶制御手段６０がデータベースサーバ２に記憶している、ユーザのゲームに関する情報であるユーザ情報データベースの一例（この例ではユーザＩＤ＝０００００１の１人分の情報）を、図１３に示す。

ユーザ情報記憶制御手段６０は、ユーザＩＤと対応付けて、ユーザの基本情報、レベル情報、キャラクタ情報、アイテム情報、ポイント情報、友達情報、アクセスログ、ゲーム内交流履歴等を、データベースサーバ２の所定の記憶領域に記憶する。

ユーザの基本情報としては、ＳＮＳ会員ＩＤ、パスワード、ユーザ名等がある。ここで、ＳＮＳ会員ＩＤとゲームのユーザＩＤとが同一の場合、ＳＮＳ会員ＩＤの情報の記憶を省略することができる。パスワードは、各ユーザが端末装置３を操作してゲームサーバ１にアクセスしたときのログイン認証に用いられる。ユーザ名は、基本的にユーザがＳＮＳで登録している名前であるが、ゲーム内でのみ使用するニックネームとすることもできる。レベル情報は、ユーザの現在のゲームレベルである。

キャラクタ情報とは、ユーザのマイキャラクタのパラメータ（能力、調子等）の情報である。キャラクタの能力としては、前述のように、パワー、ミート、弾道、走力、肩力、守備力などがある。前述のように、キャラクタの能力は、調子パラメータによって変化する。また、キャラクタの能力は、キャラクタに装着するアイテム（バット、グローブ、スパイク等）によって変化するようにしてもよい。また、キャラクタ情報として、キャラクタの画像情報も併せて記憶されている。

アイテム情報とは、ゲーム内でユーザが保有しているアイテムのアイテムＩＤの情報である。ゲームサーバ１は、ユーザがゲーム内でアイテムを入手する毎に、アイテム情報を更新する。また、ポイント情報とは、ゲーム内でユーザが保有しているポイント（経験値、体力等）の情報である。ゲームサーバ１は、ユーザがゲーム内でポイントを獲得したり、消費したりする毎に、保有ポイントの情報を更新する。

また、友達情報とは、ユーザ（第１ユーザ）のＳＮＳの友達（第２ユーザ）の情報である。友達情報として、第１ユーザのユーザＩＤと対応付けられて、第２ユーザのＳＮＳ会員ＩＤが記憶される。第１ユーザのＳＮＳの友達情報は、ゲームサーバ１がＳＮＳサーバ１０１と通信して、ＳＮＳサーバ１０１から取得できる。また、第１ユーザのＳＮＳの友達である第２ユーザがゲームに登録しているか否かの情報として、ゲーム登録フラグも記憶される。例えば、ゲーム登録フラグ＝１は「ゲームに登録済」、ゲーム登録フラグ＝０は「ゲームに未登録」を表す。

また、アクセスログとは、ユーザの端末装置３がゲームサーバ１へアクセス（ログイン）した日時等の時間情報である。また、ゲーム内交流履歴とは、ユーザがゲームに登録している他のユーザにゲーム内で交流を行った履歴の情報である。このゲーム内交流履歴には、交流の種類、相手、時間の情報が含まれる。ゲーム内交流の種類としては、挨拶、メッセージ送信、プレゼントなどがある。交流の相手の情報として、相手のユーザＩＤが記憶される。ゲーム内交流は、ＳＮＳの交流とは異なり、ゲームに登録しているユーザ間でのみ可能である。

ところで、本実施の形態では、ＳＮＳの交流情報は、ＳＮＳサーバ１０１が管理している。よって、ゲームサーバ１は、ＳＮＳサーバ１０１と通信し、ＳＮＳの交流情報をＳＮＳサーバ１０１から取得する。

次に、図１２に示す受信手段６１、実行手段６２、画面生成手段６３、送信手段６４について説明する。受信手段６１および送信手段６４は、主に、ゲームサーバ１のＣＰＵ１１および通信制御部１５により実現される機能である。

ユーザの端末装置３にゲーム画面が表示されているとき、ユーザがゲーム画面上の選択可能なボタンオブジェクトやハイパーリンクが設定された文字列等を選択する入力の操作を行った場合、当該入力に関する情報（ゲーム画面のリクエスト等）が端末装置３からゲームサーバ１へ送信される。また、端末装置３で実行されたゲーム結果の情報等が端末装置３からゲームサーバ１へ送信される。ゲームサーバ１では、前記情報を受信手段６１が受信した場合、実行手段６２が、当該情報に応じてユーザのゲームに関する情報を読み出して演算やデータ処理を実行する。このとき、ゲームサーバ１は、必要に応じてＳＮＳサーバ１０１と通信し、ＳＮＳサーバ１０１からＳＮＳ交流情報等を取得する。すなわち、受信手段６１がＳＮＳサーバ１０１から必要な情報を受信し、その情報に基づいて実行手段６２が演算やデータ処理等を実行する。また、ゲームサーバ１は、実行手段６２によって実行された処理結果の情報を、記憶装置（ＲＡＭ１３、データベースサーバ２等）の所定の領域に記憶する。

次に、画面生成手段６３について説明する。画面生成手段６３は、実行手段６２による実行結果に応じて、ＨＴＭＬデータ等からなるゲーム画面データ（例えば、図６のスタメン一覧画面データ）を生成する。また、ゲーム画面データには、プラグインによって動作するスクリプト（プログラム）が埋め込まれていてもよい。ゲームサーバ１から提供されたスクリプトが端末装置３で実行される場合は、端末装置３で表示されるゲーム画面を動画とすることも可能である。あるいは、画面生成手段６３は、ストリーミング形式の映像を生成してもよい。

また、送信手段６４は、画面生成手段６３により生成された画面データ（ＨＴＭＬデータ、ストリーミング形式の映像データ等）を、ゲーム画面のリクエストに対するレスポンスとして、または実行手段６２による実行結果として、ユーザの端末装置３へ送信する。このゲーム画面データを受信したユーザの端末装置３では、ゲーム実行プログラム、ウェブブラウザ、プラグイン等によって表示部３５にゲーム画面が表示される。

次に、アクセス管理手段６５について説明する。アクセス管理手段６５は、ゲームサービスを受けようとするユーザが端末装置３を操作してゲームサーバ１にアクセス（ログイン）しようとした際、当該ユーザのゲーム参加資格の有無を判断してログイン認証を行う。この認証の例としては、ユーザＩＤおよびパスワードに基づく認証がある。また、ユーザがゲームサーバ１にアクセスする度にユーザＩＤおよびパスワードを入力する手間を省略できるように、端末装置３の個体識別番号（電話番号とは別の端末を一意に識別するための情報）、または契約者固有ＩＤ（端末の契約者を一意に識別するための情報であって、機種変更を行っても契約者が同一である限りは変更されないＩＤ）を利用した認証を行ってもよい。

次に、交流制御手段６６について説明する。交流制御手段６６は、ゲーム内で行われるユーザ同士の交流やコミュニケーションを実現するものである。交流制御手段６６は、ユーザの端末装置３から、他のユーザ（特に、仲間）に対して所定の交流を行う情報を受信し、受信した情報に基づいて、当該ユーザから当該他のユーザに対しての交流処理を実行する実行手段６２を制御する。ゲーム内の交流処理には、挨拶、メッセージの伝達、アイテムのプレゼントなどがある。前述のように、ゲーム内の交流は、ＳＮＳの交流とは区別される。

次に、図１４の機能ブロック図等を参照して、ゲーム管理装置（ゲームサーバ１およびデータベースサーバ２）の主要な機能的構成について説明する。図１４に示すように、ゲーム管理装置としてのゲームサーバ１は、主に、対応付け手段７１、取得手段７２および決定手段７３を備えている。これらの各手段は、ゲームサーバ１のＣＰＵ１１が、本実施の形態に係るプログラムを実行することにより実現されるものである。

ゲーム管理装置としてのゲームサーバ１は、第１ユーザと所定の関係がある複数の第２ユーザのそれぞれとの間で所定の交流が可能なコミュニティサービス（例えばＳＮＳ）と連携してゲームを進行させる。ここで、コミュニティサービスにおける交流とは、第１ユーザと第２ユーザとの間で、ネットワークを介して、文字情報、画像情報または音声情報等が、一方的にまたは相互に伝達されることである。コミュニティサービスにおける所定の交流には、前述した、通話、チャット、メッセージの送信、写真やイラスト画像の送信等の種々の交流を含めることができる。コミュニティサービスとしては、ＳＮＳ、インターネット電話サービス、チャットサービス等を含む。

通話やチャットは、第１ユーザと前記第２ユーザとの間で、文字情報、画像情報または音声情報が相互に伝達される一例である。また、電子メール等のメッセージの送信は、第１ユーザと前記第２ユーザとの間で、文字情報等が一方的に相手に伝達される一例である。

また、コミュニティサービスと連携してゲームを進行させるとは、ゲーム外サービスであるコミュニティサービスにおける情報を、ゲーム進行において参照したり利用したりできることを意味する。本実施の形態のゲームサーバ１は、通話、チャット、メッセージの送信、イラスト画像の送信等が可能なＳＮＳと連携してゲームを進行させる。

対応付け手段７１は、第１ユーザが利用するゲームにおける複数のキャラクタに、ＳＮＳにおいて第１ユーザと所定の関係がある複数の第２ユーザの少なくとも一部のそれぞれを対応付ける機能を有する。本実施の形態では、図６に例示するように、第１ユーザのゲーム内野球チームの複数の選手キャラクタに、複数の第２ユーザの少なくとも一部のそれぞれが対応付けられる。これにより、例えば、第１ユーザのゲーム内野球チームには、第２ユーザの名前（またはニックネーム、あるいはアバター画像等）が対応付けられたキャラクタが所属することになる。すなわち、第２ユーザは、第１ユーザのゲーム内グループのキャラクタと対応付けられることにより、仮想的に第１ユーザのゲーム内グループのメンバとなる。

ところで、ＳＮＳにおいて第１ユーザと所定の関係がある第２ユーザの人数ｎが、第１ユーザが利用するゲームにおける複数のキャラクタの数ｍよりも大きい場合（ｎ＞ｍ）は、第２ユーザの一部が、複数のキャラクタのそれぞれと対応づけられる。複数のキャラクタの数ｍは、第２ユーザが対応づけられるキャラクタの数を表すものであり、第１ユーザのマイキャラクタの数は含まれない。図６の例では、複数のキャラクタの数ｍは「９」である。

一方、ＳＮＳにおいて第１ユーザと所定の関係がある第２ユーザの人数ｎが、第１ユーザが利用するゲームにおける複数のキャラクタの数ｍ以下の場合（ｎ≦ｍ）は、全ての第２ユーザがキャラクタに対応づけられることになる。特に、ｎ＜ｍの場合には、第２ユーザと対応づけられないキャラクタが発生する。この場合は、第２ユーザと対応づけられない汎用キャラクタ（ＣＰＵキャラクタ）が適用される。

取得手段７２は、ＳＮＳにおける前記第１ユーザと前記第２ユーザとの間の交流度合を取得する機能を有する。なお、第１ユーザと第２ユーザとの交流が多いほど、両者は親密で友好的な関係であるといえることから、「交流度合い」を、「親密度」、「友好度」等の呼称で表してもよい。

例えば、取得手段７２は、ＳＮＳにおける第１ユーザと第２ユーザの各々との間の交流情報（交流履歴等）に基づいて、交流度合い（交流回数、交流頻度、交流ポイント等）を求める。

あるいは、ＳＮＳ等のコミュニティサービスにおいて交流度合いの情報が存在すれば、取得手段７２は、コミュニティサービスから交流度合いの情報を直接取得してもよい。例えば、ＳＮＳサーバ１０１において、ユーザ間の交流回数または交流頻度に応じた親密度を管理している場合、取得手段７２は、ＳＮＳサーバ１０１と通信して、前記親密度の情報を交流度合いとして取得することができる。

以下の説明では、取得手段７２が、ＳＮＳにおける第１ユーザと第２ユーザの各々との間の交流情報に基づいて、交流度合いを自ら算出する例について説明する。

図１５の機能ブロック図に、交流情報取得手段７２ａと、交流度合算出手段７２ｂとからなる取得手段７２の構成例を示す。

交流情報取得手段７２ａは、ＳＮＳにおける第１ユーザと第２ユーザの各々との間の交流情報を取得する機能を有する。ゲームサーバ１とＳＮＳサーバ１０１とが別のコンピュータによって構成されている場合、交流情報取得手段７２ａは、ＳＮＳサーバ１０１に対して第１ユーザ（第１ユーザのＳＮＳ会員ＩＤ）の交流情報を要求し、ＳＮＳサーバ１０１から、ＳＮＳにおける第１ユーザと第２ユーザの各々との間の交流情報を取得する。また、ゲームサーバ１とＳＮＳサーバ１０１とが同一のコンピュータとして構成されている場合、交流情報取得手段７２ａは、コンピュータ内部のデータ処理によって、ＳＮＳにおける第１ユーザと第２ユーザの各々との間の交流情報を取得する。

ここで、ＳＮＳサーバ１０１において管理されているＳＮＳの交流情報（交流ＤＢ）の一例を、図１６に示す。同図は、ＳＮＳ会員ＩＤ＝０００００１の第１ユーザＡについてのＳＮＳの交流情報を示している。このＳＮＳの交流情報は、記憶装置としてのＳＮＳデータベースサーバ１０２に記憶されている。ＳＮＳの交流情報には、例えば、交流ＩＤ、交流の種類、交流の相手、交流が行われた日時、交流の内容、通話時間などの情報が含まれる。交流ＩＤは、第１ユーザと第２ユーザとの間の交流を一意に識別するための情報である。交流の種類は、種類コードによって管理されている。交流の種類としては、１０＝通話（電話を掛ける）、１１＝通話（電話を受ける）、２０＝メッセージ送信、２１＝メッセージ受信、３０＝イラスト画像送信、３１＝イラスト画像受信、等がある。交流の相手の情報としては、相手のＳＮＳ会員ＩＤが記憶される。また、交流の内容としては、交流がメッセージの送受の場合はそのメッセージの情報が記憶され、交流がイラスト画像の送受の場合はそのイラスト画像の情報が記憶される。また、交流が通話の場合、通話時間の情報が記憶される。

例えば、ゲームサーバ１の交流情報取得手段７２ａが第１ユーザＡのＳＮＳの交流情報を取得する場合、第１ユーザＡのＳＮＳ会員ＩＤ＝０００００１を指定して、ＳＮＳサーバ１０１に交流情報を要求する。これにより、ＳＮＳサーバ１０１は、ＳＮＳ会員ＩＤ＝０００００１の第１ユーザと第２ユーザの各々との間の交流情報をＳＮＳデータベースサーバ１０２から読み出して、必要な情報をゲームサーバ１に返す。交流情報取得手段７２ａが取得したＳＮＳの交流情報は、記憶装置（ＲＡＭ１３等）に保存される。

本実施の形態では、第１ユーザが野球ゲームを遊戯する毎に、第１ユーザのチームのスタメンを決定するために、交流情報取得手段７２ａが、ＳＮＳの交流情報を取得する。なお、これに限定されるものではなく、例えば１日に１回だけ（その日の最初のゲームプレイ時に）、交流情報取得手段７２ａがＳＮＳの交流情報を取得するようにしてもよい。

交流度合算出手段７２ｂは、交流情報取得手段７２ａによって取得された、第１ユーザと第２ユーザの各々との間のＳＮＳの交流情報に基づいて、ＳＮＳにおける第１ユーザと第２ユーザの各々との間の交流度合いを算出する機能を有する。

ここで、交流度合いの一例としては、所定期間（例えば、過去１日、１週間、１か月等）における交流回数または交流頻度が挙げられる。あるいは、第１ユーザと第２ユーザとの間の交流に対して交流ポイントを対応付け、交流度合いを、所定期間における交流ポイントの合計として算出してもよい。

取得手段７２の交流度合算出手段７２ｂは、ＳＮＳにおける第１ユーザと第２ユーザとの間の交流内容に応じた交流ポイントによって、交流度合いを算出することが好ましい。ＳＮＳの交流の内容に応じた交流ポイントの一例としては、図１７に示すように、通話（電話を掛ける、または受ける）：１０ポイント／回、メッセージの送信または受信：５ポイント／回、イラスト画像の送信または受信：２ポイント／回とすることができる。通話は、第１ユーザがかなり親しい第２ユーザと行う現実世界の交流であることから、メッセージ送信やイラスト画像の送信よりも、１回の交流当たりのポイント大きくしている。また、相手に簡単に送信できるイラスト画像の送信よりも、メッセージの送信の交流ポイントを大きくしている。これにより、ＳＮＳにおける現実世界の交流内容に応じた適切な交流度合いの評価が可能となる。

なお、ＳＮＳの交流と交流ポイントとの関係は、図１７に限定されない。例えば通話、メッセージの送信または受信、イラスト画像の送信または受信の全てについて、交流ポイントを同一（例えば１ポイント）としてもよい。

また、通話による交流ポイントは、通話時間によって値を変えてもよい（通話時間が長いほど交流ポイントを大きくする）。例えば、通話の基本ポイントを、１０ポイント／回とし、通話時間が１０分を超える毎に１ポイントを加算する。但し、最大で例えば１５ポイントまでとする。この場合、ゲームサーバ１は、ＳＮＳサーバ１０１から、ＳＮＳの交流情報として通話時間の情報も取得する。なお、第１ユーザが特定の第２ユーザとの交流ポイントを稼ぐためだけに、僅か数秒だけの通話を繰り返すことを防止するため、通話時間が所定時間（例えば３０秒）よりも短い通話については、交流の評価の対象から除外してもよい。

また、メッセージ送信または受信による交流ポイントは、その文章の長さ（文字数）によって値を変えてもよい（文章が長いほど交流ポイントを大きくする）。例えば、メッセージ送信または受信の基本ポイントを、５ポイント／回とし、文字数が１００文字を超える毎に１ポイントを加算する。但し、最大で例えば８ポイントまでとする。この場合、ゲームサーバ１は、ＳＮＳサーバ１０１から、ＳＮＳの交流情報としてメッセージの文字数に関する情報（文字数、バイト数等）も取得する。なお、第１ユーザが特定の第２ユーザとの交流ポイントを稼ぐためだけに、僅か数文字だけのメッセージの送信を繰り返すことを防止するため、メッセージの文字数が所定数（例えば５文字）よりも短い交流については、交流の評価の対象から除外してもよい。

上記のように、交流の内容に応じた任意の交流ポイントを定めることができる。そして、交流度合算出手段７２ｂは、例えば、所定期間（過去１か月、過去１週間等）における交流相手毎の交流ポイントの合計値によって、第１ユーザと第２ユーザの各々との間の交流度合いを算出する。

また、取得手段７２の交流度合算出手段７２ｂは、第１ユーザから第２ユーザへＳＮＳの交流が行われた場合と、第２ユーザから第１ユーザへＳＮＳの交流が行われた場合とで、前記交流ポイントを異ならせてもよい。例えば、前者の場合の交流ポイントを、後者の場合の交流ポイントよりも大きくする。具体例を挙げると、図１８に示すように、通話の場合、第１ユーザが第２ユーザに電話を掛ける場合の交流ポイントを、「１２ポイント／回」とする一方、第１ユーザが第２ユーザから電話を受ける場合の交流ポイントを、「８ポイント／回」とする。また、メッセージについては、第１ユーザが第２ユーザにメッセージを送信する場合の交流ポイントを、「６ポイント／回」とする一方、第１ユーザが第２ユーザからメッセージを受信する場合の交流ポイントを、「４ポイント／回」とする。また、イラスト画像については、第１ユーザが第２ユーザにイラスト画像を送信する場合の交流ポイントを、「２ポイント／回」とする一方、第１ユーザが第２ユーザからイラスト画像を受信する場合の交流ポイントを、「１ポイント／回」とする。これは、第１ユーザ自らが第２ユーザに対して通話等の交流を行ったということは、第１ユーザがその第２ユーザに対して親しみを感じていることの表れであり、これを交流ポイントに反映させたものである。この場合、第１ユーザの方からよく交流をしている第２ユーザのキャラクタが、第１ユーザのチームのスタメンに選択され易くなる。

あるいは、逆に、第２ユーザから第１ユーザへＳＮＳの交流が行われた場合の交流ポイントを、第１ユーザから第２ユーザへＳＮＳの交流が行われた場合の交流ポイントよりも大きくしてもよい。具体例を挙げると、図１９に示すように、通話の場合、第１ユーザが第２ユーザに電話を掛ける場合の交流ポイントを、「８ポイント／回」とする一方、第１ユーザが第２ユーザから電話を受ける場合の交流ポイントを、「１２ポイント／回」とする。また、メッセージについては、第１ユーザが第２ユーザにメッセージを送信する場合の交流ポイントを、「４ポイント／回」とする一方、第１ユーザが第２ユーザからメッセージを受信する場合の交流ポイントを、「６ポイント／回」とする。また、イラスト画像については、第１ユーザが第２ユーザにイラスト画像を送信する場合の交流ポイントを、「１ポイント／回」とする一方、第１ユーザが第２ユーザからイラスト画像を受信する場合の交流ポイントを、「２ポイント／回」とする。これは、第２ユーザから第１ユーザに対して通話等の交流が行われたということは、第１ユーザがその第２ユーザから親しみを感じられていることの表れであり、これを交流ポイントに反映させたものである。この場合、第１ユーザに対してよく交流してくれる第２ユーザのキャラクタが、第１ユーザのチームのスタメンに選択され易くなる。

次に、図１４または図１５に示す決定手段７３について説明する。決定手段７３は、前記交流度合い（上記交流ポイントの合計値等）に基づいて、ＳＮＳで第１ユーザと所定の関係がある複数の第２ユーザの中から、前記対応付け手段７１によって第１ユーザの複数のキャラクタに対応付けられる第２ユーザを決定する機能を有する。

本実施の形態では、対応付け手段７１および決定手段７３により、「前記交流度合いに基づいて、前記第１ユーザが利用するゲームにおける複数のキャラクタに、前記複数の第２ユーザの少なくとも一部をそれぞれ対応付ける対応付け手段」が構成されている。図１４以降の機能ブロック図では、対応付け手段７１と決定手段７３とを別構成とする例を示しているが、決定手段７３の機能を対応付け手段７１に包含させることにより両手段を「対応付け手段」として統合することもできる。この場合、図１４以降の機能ブロック図において、決定手段７３を省くことができる。

例えば、決定手段７３は、所定期間（過去１か月、過去１週間等）における交流ポイントの合計値の大きい上位９人の第２ユーザを、第１ユーザのチームのスタメンのキャラクタに対応付けられる第２ユーザとして決定する。この場合、一旦、スタメンとして選ばれた第２ユーザであっても、第１ユーザとの間のＳＮＳの交流が少なくなれば、所定期間における交流ポイントの合計値が低下し、スタメンから外れることがある。

あるいは、決定手段７３は、前記交流ポイントの合計値が所定の閾値未満の（すなわち、ほとんど交流のない）第２ユーザを除外した中から、ランダムに、第１ユーザのチームのスタメンのキャラクタに対応付けられる第２ユーザを決定してもよい。あるいは、決定手段７３は、前記交流ポイントの合計値が所定の閾値以上である第２ユーザの中から、ランダムに、第１ユーザのチームのスタメンのキャラクタに対応付けられる第２ユーザを決定してもよい。

対応付け手段７１は、決定手段７３によって決定された複数の第２ユーザを、第１ユーザのチームのスタメンのキャラクタのそれぞれに対応付ける。図２０には、第１ユーザのゲーム内キャラクタに関する情報の一例を示す。この情報は、第１ユーザのユーザＩＤと関係づけて、記憶装置の一例としてのデータベースサーバ２に記憶される。図２０は、第１ユーザが、ユーザＩＤ＝０００００１のユーザである場合を例示している。第１ユーザのチームのスタメンのキャラクタには、各キャラクタを一意に識別するためのキャラクタＩＤが設けられている。そして、各キャラクタＩＤと対応付けて、決定手段７３によって決定された第２ユーザのＩＤ（ＳＮＳ会員ＩＤ）が記憶されることにより、キャラクタと第２ユーザとの対応付けが行われる。

なお、図２０の例では、キャラクタＩＤ＝１が第１ユーザのマイキャラクタであり、キャラクタＩＤ＝２〜１０が第２ユーザのキャラクタである。各キャラクタには、打順、ポジション、能力等のパラメータが設定される。ここで、各キャラクタの打順やポジションについては、ゲームサーバ１がランダムに決定してもよいし、交流度合いに基づいて決定してもよい。また、ゲームサーバ１は、第１ユーザのマイキャラクタの能力および各第２ユーザのキャラクタの基本能力を設定する。この基本能力の設定の詳細については後述する。

また、図２１に例示するように、ゲームサーバ１は、前述の構成の他に、役割決定手段７４をさらに備えていることが好ましい。この役割決定手段７４は、前記交流度合いに基づいて、第２ユーザと対応付けられたキャラクタの役割を決定する機能を有する。ここで、第２ユーザと対応付けられたキャラクタの役割を決定するとは、例えば攻撃・防御の順番、ポジション等の決定を言う。本野球ゲームでは、攻撃の順番であるオーダー（打順）や、ポジション（守備位置）の決定が、役割の決定に該当する。具体例を、以下に示す。

役割決定手段７４は、例えば、交流度合いが大きい第２ユーザのキャラクタを、クリーンナップまたは上位打線に自動的に設定する。一例を挙げると、上記交流ポイントの合計値が大きい順に、４→３→５→１→２→６→７→８→９の打順に、第２ユーザのキャラクタを設定する。この構成の場合、一旦、クリーンナップまたは上位打線に設定された第２ユーザのキャラクタであっても、第１ユーザとその第２ユーザとの現実世界での交流（ＳＮＳでの交流）が少なくなると、その第２ユーザのキャラクタの打順は、自動的に下位打線に変更される。なお、第１ユーザのマイキャラクタの打順については、第１ユーザの操作に基づいて（または第１ユーザの操作がなくとも）、予め所定の打順（例えば、１番、４番等）に固定することができる。

また、守備に特化したゲームモードまたは守備を含むゲームモードにおいては、役割決定手段７４は、前記交流度合いに基づいて、第２ユーザのキャラクタのポジションを決定する。例えば、上記交流ポイントの合計値が大きい順に、投手→捕手→遊撃手→二塁手→中堅手→三塁手→右翼手→一塁手→左翼手のポジションに、第２ユーザのキャラクタを設定する。もちろん、前記交流度合いに基づいて、第２ユーザのキャラクタの打順およびポジションの両方を決定してもよい。

本構成により、ＳＮＳにおける第１ユーザと第２ユーザの各々との交流度合いに基づいて、第１ユーザのゲーム内グループのメンバとなる第２ユーザのキャラクタを自動設定するだけでなく、第２ユーザのキャラクタのグループ内の役割も自動的に決定することができる。これにより、第１ユーザがＳＮＳでよく交流している第２ユーザのキャラクタが、第１ユーザのゲーム内グループで重要な役割を担うようにすることができ、ゲームを通して、親しい第２ユーザとのつながりをより強めることができる。

ここで、第１ユーザが野球ゲームを遊戯する場合のゲームサーバ１の動作例を、図２２のフローチャートを参照しながら、以下に説明する。

第１ユーザが端末装置３で野球ゲームを開始する操作を行った場合、端末装置３からゲームサーバ１へ、ゲーム開始の操作情報が送信される。ゲームサーバ１は、第１ユーザの端末装置３からゲーム開始の操作情報を受信したとき（Ｓ１でＹＥＳ）、当該第１ユーザと第２ユーザの各々との間のＳＮＳの交流情報を取得する（Ｓ２）。すなわち、ゲームサーバ１は、第１ユーザのＳＮＳ会員ＩＤを指定して、ＳＮＳサーバ１０１に当該第１ユーザの交流情報を要求する。この場合、ゲームサーバ１は、交流の評価対象となる期間（例えば過去１か月、１週間等）を指定して、ＳＮＳサーバ１０１に要求することが好ましい。この要求に対するＳＮＳサーバ１０１からのレスポンスとして、ゲームサーバ１は、第１ユーザと第２ユーザの各々との間のＳＮＳの交流情報を受信する。ゲームサーバ１は、取得したＳＮＳの交流情報を、記憶装置（ＲＡＭ１３等）に記憶する。

その後、ゲームサーバ１は、取得したＳＮＳの交流情報に基づいて、ＳＮＳにおける第１ユーザと第２ユーザの各々との間の交流度合いを算出する（Ｓ３）。すなわち、ゲームサーバ１は、例えば図１７、図１８または図１９に示すＳＮＳの交流と交流ポイントとの関係に基づいて、所定期間内における第１ユーザの交流相手（第２ユーザ）毎の交流ポイントの合計値を、交流度合いとして算出する。

その後、ゲームサーバ１は、ステップＳ３によって算出された交流度合いに基づいて、複数の第２ユーザの中から、第１ユーザのチームのスタメンのキャラクタに対応付けられる所定人数（本実施の形態では９人）の第２ユーザを決定する（Ｓ４）。例えば、ゲームサーバ１は、所定期間における交流度合いの大きい上位９人の第２ユーザを、第１ユーザのチームのスタメンのキャラクタに対応付けられる第２ユーザとして決定する。

その後、ゲームサーバ１は、ステップＳ４によって決定された９人の第２ユーザを、第１ユーザのチームのスタメンのキャラクタに対応付ける。例えば、図２０に示すように、スタメンのキャラクタＩＤ＝２〜１０に、ステップＳ４によって決定された９人の第２ユーザのＳＮＳ会員ＩＤのそれぞれを対応付ける。

また、ゲームサーバ１は、前記９人の第２ユーザのキャラクタの打順を、第１ユーザと当該第２ユーザとの交流度合いに基づいて決定する（Ｓ５）。例えば、図６のように第１ユーザのマイキャラクタを１番打者として固定する場合、交流度合いの大きい順に、４→３→５→２→６→７→８→９の打順となるように、各第２ユーザのキャラクタの打順を決定する。また、前記９人の第２ユーザのうち最も交流度合いの小さい第２ユーザのキャラクタを、打席に立たない（打順のない）投手として設定する。

図６の例では、指名打者（ＤＨ）のキャラクタがいるため、投手キャラクタは打席に立たない。攻撃のみに特化したゲーム形式では、打席に立たない投手キャラクタを省いてもよい。この場合、ステップＳ４において、８人の第２ユーザが、第１ユーザのチームのスタメンのキャラクタに対応付けられる第２ユーザとして選択される。もっとも、野球のルールとして指名打者制を採用しない場合、投手キャラクタも打席に立つ。指名打者制を採用しない場合には、指名打者（ＤＨ）のキャラクタが省かれる。

上記のようにして決定された各キャラクタの打順は、図２０に例示する第１ユーザのゲーム内キャラクタに関する情報として記憶される。

また、ゲームサーバ１は、前記９人の第２ユーザのキャラクタのポジション（守備位置）を決定する（Ｓ７）。攻撃のみに特化したゲーム形式では、ポジションはあまり重要ではないので、ゲームサーバ１が、各第２ユーザのキャラクタのポジションをランダムに決定してもよい。あるいは、打順と同様に、ゲームサーバ１が、交流度合いに基づいて、各第２ユーザのキャラクタのポジションを決定してもよい。なお、第１ユーザのマイキャラクタのポジションについては、予め決まったポジションに固定してもよいし、例えばランダムに決定してもよい。上記のようにして決定された各キャラクタのポジションは、図２０に例示する第１ユーザのゲーム内キャラクタに関する情報として記憶される。

また、ゲームサーバ１は、前記９人の第２ユーザのキャラクタの基本能力を設定する（Ｓ８）。例えば、第１ユーザのチーム内の全ての第２ユーザのキャラクタの基本能力を同一としてもよいし、第２ユーザがゲームに登録しているか否かによって、第２ユーザのキャラクタの基本能力を異ならせてもよい。あるいは、ゲームに登録済みの第２ユーザのキャラクタの基本能力を当該第２ユーザ自身のマイキャラクタの能力としてもよい。あるいは、後述するように、キャラクタの打順またはポジションに応じて、予め定められた基本能力を適用してもよい。設定された各キャラクタの基本能力は、図２０に例示する第１ユーザのゲーム内キャラクタに関する情報として記憶される。なお、第１ユーザのマイキャラクタの能力については、図１３のキャラクタ情報として記憶されている能力が適用される。

その後、ゲームサーバ１は、図２０に例示する第１ユーザのゲーム内キャラクタに関する情報に基づいて、図６に例示するスタメン発表画面のデータを生成し（Ｓ９）、第１ユーザの端末装置３に送信する（Ｓ１０）。このとき、ゲームサーバ１は、画面のデータと共に、第１ユーザのゲーム内キャラクタに関する情報も併せて送信する。

これにより、第１ユーザの端末装置３には、図６に例示するスタメン発表画面が表示される。その後、第１ユーザは、プレイボタン２１０を押して、各キャラクタを使用した打撃を開始してもよいし、その前に、キャラクタに対応付けられた第２ユーザを変更したり、キャラクタの打順を入れ替えたりしてもよい。

以上のように、本実施の形態の構成では、ＳＮＳにおける第１ユーザと第２ユーザとの交流度合いが評価されて、ＳＮＳで第１ユーザと所定の関係がある複数の第２ユーザの中から、第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザが自動的に決定される。通常、第１ユーザにとって、ＳＮＳで通話やチャット等の交流を行う第２ユーザは、現実世界で繋がりのある間柄である。すなわち、本構成では、ＳＮＳにおいて交流している現実世界の友達等の第２ユーザが、第１ユーザ自身のゲーム内キャラクタと対応付けられて、ゲームに登場する。これにより、第１ユーザは、ゲームを遊戯する毎に、自己のゲームに登場する第２ユーザのキャラクタを通して、間接的に親しみを感じることになる。よって、第１ユーザは、ＳＮＳにおける交流のみならず、ゲームを通しても、第２ユーザとのつながりを強め、延いてはゲームに対する関心と興味をより強める結果となる。よって、本構成のゲーム管理装置は、各ユーザにとって飽きのこない継続性を有するゲームサービスの提供を実現できる。

次に、ＳＮＳのプロフィール情報に基づいて、第２ユーザのキャラクタの役割を調整する好ましい構成について説明する。この構成のゲームサーバ１は、図２３に例示するように、前述の構成の他に、プロフィール情報取得手段７５をさらに備えている。このプロフィール情報取得手段７５は、ＳＮＳにおける第２ユーザのプロフィール情報を取得する機能を有する。

図３に例示するように、ＳＮＳにおいて、各ユーザは、自分の名前、年齢、性別、出身地、住所、趣味等のユーザ自身の種々のプロフィール情報を登録している。このプロフィール情報はＳＮＳサーバ１０１において管理されているので、プロフィール情報取得手段７５は、ＳＮＳサーバ１０１と通信し、第２ユーザのプロフィール情報を取得する。すなわち、プロフィール情報取得手段７５は、第１ユーザのゲーム内キャラクタに対応付けられた第２ユーザ（そのＳＮＳ会員ＩＤ）を指定し、ＳＮＳサーバ１０１に対してプロフィール情報を要求する。そして、プロフィール情報取得手段７５は、この要求に応えて、ＳＮＳサーバ１０１から送信されてくる第２ユーザのプロフィール情報を取得する。

なお、ゲームサーバ１とＳＮＳサーバ１０１とが同一のコンピュータとして構成されている場合、プロフィール情報取得手段７５は、コンピュータ内部のデータ処理によって、ＳＮＳにおける第２ユーザのプロフィール情報を取得することができる。

そして、本実施の形態の役割決定手段７４は、前記交流度合い及び前記プロフィール情報に基づいて、第２ユーザと対応付けられたキャラクタの役割（打順、ポジション等）を決定する。ここで、前記プロフィール情報には、年齢、性別、趣味の少なくとも１つの情報が含まれ、役割決定手段７４は、当該プロフィール情報に基づいて、交流度合いに基づいて決定した第２ユーザのキャラクタの役割を調整することが好ましい。

例えば、女性、子供（所定以下の年齢）、高齢者（所定以上の年齢）の第２ユーザのキャラクタについては、交流度合いに基づいて決定した打順から、１つ又は２つ以上、下位側に打順を下げる。また、スポーツを趣味としている第２ユーザのキャラクタについては、交流度合いに基づいて決定した打順から、１つ又は２つ以上、上位側に打順を上げるようにしてもよい。

このように、ＳＮＳにおいて第２ユーザが登録している現実世界の年齢等のプロフィール情報に基づいて、その第２ユーザに対応付けられたキャラクタの役割を変化させることにより、現実世界の友達等である第２ユーザの特定の属性を、ゲーム内のキャラクタに反映させることができ、ゲームの興趣性を高めることができる。

次に、第１ユーザのゲーム内キャラクタに対応付けられた第２ユーザへの通知について説明する。図２４に例示するように、ゲームサーバ１は、前述の構成の他に、通知手段７６をさらに備えていることが好ましい。この通知手段７６は、第１ユーザが利用するゲームにおける複数のキャラクタの何れかに第２ユーザが対応付けられた場合、その旨の通知を当該第２のユーザに対して行う機能を有する。

例えば、通知手段７６は、第２ユーザが第１ユーザのチームのスタメンのキャラクタに対応付けられた場合に、その旨を第２ユーザの端末装置３に自動的に通知する。例えば、「あなたのキャラクタが、友達Ａさんの野球チームのメンバに加入しました。」というメッセージが第２ユーザに通知される。あるいは、通知手段７６は、第２ユーザが第１ユーザのチームの特定のキャラクタ（例えばクリーンナップのキャラクタ）に対応付けられたことを条件として、その旨を第２ユーザの端末装置３に自動的に通知するようにしてもよい。

ここで、ゲームに未登録の第２ユーザへの通知は、ＳＮＳサーバ１０１を経由したＳＮＳのメッセージ送信により行うことができる。すなわち、通知手段７６は、第２ユーザ（そのＳＮＳ会員ＩＤ）およびメッセージ内容を指定し、ＳＮＳサーバ１０１に対して、当該第２ユーザへのＳＮＳのメッセージ送信を要求する。この要求に応えて、ＳＮＳサーバ１０１が第２ユーザにＳＮＳのメッセージを送信する。

一方、ゲームに登録済みの第２ユーザへの通知は、前述したＳＮＳのメッセージ送信またはゲーム内のお知らせ機能により行うことができる。ゲーム内のお知らせ機能とは、ゲームサーバ１が、ゲームに登録済みの第２ユーザの端末装置３へ、メッセージ等を通知する機能である。

前記の通知を受けた第２ユーザは、自分を第１ユーザのゲーム内のキャラクタとして使ってもらえていることの認識をもつので、満足感、喜びを感じることができる。本構成により、第２ユーザのキャラクタを自分のゲーム内で使う第１ユーザと、第１ユーザに自分のキャラクタを使ってもらえる第２ユーザとの間の親密さを高めることができる。

また、上記の第２ユーザへの通知は、第１ユーザのスタメンが確定した時点で行ってもよいし、第２ユーザのキャラクタがゲーム内で活躍したこと（所定の結果を出したこと）を契機として行ってもよい。好ましくは、第２ユーザと対応付けられたキャラクタが、第１ユーザが利用するゲーム内で所定の結果を発生させたことを契機として、通知手段７６が、当該第２ユーザに対して、前記通知を行うとともに、発生させた前記結果を通知する構成とする。

ここで、所定の結果の例としては、ヒット、ホームラン、打点を挙げる等の好結果が挙げられる。第１ユーザは、第２ユーザのキャラクタを使用してゲームを遊戯するが、その遊戯中に、第２ユーザのキャラクタがホームラン等の所定の結果を発生させた場合に、通知手段７６が、例えば「あなたのキャラクタが、友達Ａさんの野球チームのメンバに加入し、ホームランを打ちました。」というメッセージを、第２ユーザの端末装置３に通知する。

上記の通知を受けた第２ユーザは、自分を第１ユーザのゲーム内グループのキャラクタとして使ってもらえていることの認識をもつとともに、ゲーム内で自分のキャラクタが所定の結果を出していることから、満足感、喜びがより大きくなる。

次に、第２ユーザのキャラクタのパラメータについて説明する。このパラメータには、前述の能力や調子パラメータ以外にも、キャラクタの大きさ、色、形態、身長、体重、年齢、キャラクタの性格（積極性、攻撃性等）、ゲーム内でのキャラクタの登場頻度（回数）等、様々なパラメータを適用し得る。これらのパラメータは、数値やレベル（Ａ、Ｂ、Ｃ…等でもよい）等によって管理することができる。図２５に例示するように、ゲームサーバ１は、前述の構成の他に、第２ユーザのキャラクタの能力等のパラメータを管理するパラメータ管理手段７７をさらに備えていることが好ましい。前述のように、全ての第２ユーザのキャラクタの能力を同一としてもよいし、第２ユーザのキャラクタ毎に能力を異ならせてもよい。

前述のように、第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザとしては、ゲームに登録済みの第２ユーザだけではなく、ゲームに未登録の第２ユーザを含めることもできる。そこで、パラメータ管理手段７７は、ゲームに登録済みの第２ユーザと対応付けられたキャラクタのパラメータを、ゲームに未登録の第２ユーザと対応付けられたキャラクタのパラメータよりも大きくすることが好ましい。

この場合、第１ユーザにとっては、自分の友達等である第２ユーザがゲームに登録している方が有利である。従って、第１ユーザは、ゲーム未登録の第２ユーザに対して、ゲームに登録するように積極的に働きかけることを動機付けられる。本構成により、ゲーム未登録者のゲームへの登録を促進することができる。

ゲームに登録済みの第２ユーザのキャラクタの能力を、ゲームに未登録の第２ユーザのキャラクタの能力よりも大きくする方法としては、種々の方法が考えられる。例えば、ゲームに未登録の第２ユーザのキャラクタの能力を第１ランク（例えばＧランク）とし、ゲームに登録済みの第２ユーザのキャラクタの能力を、第１ランクよりも高い第２ランク（例えばＥランク、Ｆランク等）とする。

あるいは、ゲームに未登録の第２ユーザのキャラクタの能力を最低の「Ｇ１」とし、ゲームに登録済みの第２ユーザのキャラクタの能力については、当該第２ユーザがゲームを遊戯して向上させた第２ユーザ自身のマイキャラクタの能力を適用するものとしてもよい。すなわち、パラメータ管理手段７７は、ゲームに登録済みの第２ユーザと対応付けられたキャラクタのパラメータとして、当該第２ユーザが利用するゲームで使用されている当該第２ユーザ自身のキャラクタのパラメータを適用する機能を有する。

上記の構成により、第２ユーザが自身のゲームプレイによって第２ユーザのマイキャラクタのパラメータ（能力値等）を向上させた場合、その第２ユーザと対応付けられた、第１ユーザのゲーム内キャラクタのパラメータも向上する。よって、第１ユーザは、その向上したパラメータのキャラクタでゲームを行うことができる。

本構成の場合、第１ユーザにとっては、第２ユーザがゲームに登録している場合、第２ユーザのゲームプレイの結果が第１ユーザのゲームプレイにも反映されるので、有利である。従って、第１ユーザは、ゲーム未登録の第２ユーザに対して、ゲームに登録するように積極的に働きかけることを動機付けられる。本構成によっても、ゲーム未登録者のゲームへの登録を促進することができる。

次に、ゲーム未登録者のゲームへの登録を促進することができる好ましい構成について説明する。図２６に例示するように、ゲームサーバ１は、前述の構成の他に、表示制御手段７８と、招待情報通知手段７９と、パラメータ向上手段８０とをさらに備えていることが好ましい。

前記表示制御手段７８は、第１ユーザのゲーム内の複数のキャラクタの何れかと対応付けられた第２ユーザのうち、ゲームに未登録の第２ユーザに対して、ゲームに招待するための招待操作部を、第１ユーザのゲーム画面に表示させる機能を有する。招待操作部の一例は、図１０の画面中の招待ボタン２０６である。表示制御手段７８は、ゲームに未登録の第２ユーザのキャラクタに対応付けて招待ボタン２０６を設けた図１０の画面を表示させる画面データ（画面表示制御データ）を生成し、これを第１ユーザの端末装置３へ送信する。この画面データを受信した第１ユーザの端末装置３の表示部３５には、招待ボタン２０６を含む図１０の画面が表示される。

前記招待情報通知手段７９は、招待操作部の一例としての招待ボタン２０６を選択する操作が行われた場合に、ゲームに未登録の第２ユーザに対して、ゲームへ招待する情報を通知する機能を有する。

例えば、招待情報通知手段７９は、ゲームへ招待する情報の一例として、「友達Ａさんがあなたを野球ゲームに招待しています。」という招待メッセージを、第２ユーザの端末装置３に通知する。この招待メッセージには、ゲームサーバ１（またはＳＮＳサーバ１０１）が管理するゲームへの新規登録ページのＵＲＬのハイパーリンクが含まれている。また、このＵＲＬには、例えば、招待した第１ユーザの情報（ユーザＩＤ）も含まれている。例えば、招待した第１ユーザがユーザＩＤ＝“０００００１”の場合、ＵＲＬは、「http://・・・invite_user_id=000001・・・」等となる。よって、招待を受けた第２ユーザが招待メッセージ中のＵＲＬを選択する操作を行うことによって、ゲームサーバ１は、招待した第１ユーザを認識することができる。これにより、第２ユーザがゲームに新規登録した場合、ゲームサーバ１は、第１ユーザおよび第２ユーザの両方（または何れか一方）に、ゲーム内ポイント等の特典を付与することもできる。

ゲームサーバ１とＳＮＳサーバ１０１とが別のコンピュータによって構成されている場合、前記招待メッセージの第２ユーザへの通知は、ＳＮＳサーバ１０１を経由したＳＮＳのメッセージ送信により行うことができる。すなわち、招待情報通知手段７９は、第２ユーザ（そのＳＮＳ会員ＩＤ）およびメッセージ内容を指定し、ＳＮＳサーバ１０１に対して、当該第２ユーザへのＳＮＳのメッセージ送信を要求する。この要求に応えて、ＳＮＳサーバ１０１が第２ユーザにＳＮＳのメッセージを送信する。

一方、ゲームサーバ１とＳＮＳサーバ１０１とが同一のコンピュータによって構成されている場合、招待情報通知手段７９は、第２ユーザの端末装置３に、前記招待メッセージを直接送信する。

このように、本実施の形態では、第１ユーザは、ゲームに招待したい第２ユーザの招待ボタン２０６を押すだけで、簡単に、その第２ユーザをゲームに招待することができる。

前記パラメータ向上手段８０は、招待操作部の一例としての招待ボタン２０６を選択する操作が行われた場合に、ゲームに未登録の前記第２ユーザと対応付けられたキャラクタのパラメータを、当該操作が行われない場合よりも向上させる機能を有する。例えば、パラメータ向上手段８０は、招待ボタン２０６が押された第２ユーザのキャラクタの能力を、所定ランク向上させたり、所定量または所定割合向上させたりする。具体例としては、招待ボタン２０６が押された第２ユーザのキャラクタの能力を、ＧランクからＦランクへ１ランク向上させる。

このパラメータ向上効果は、１回のゲームプレイのみ有効としてもよいし、所定期間（例えば１日間）有効としてもよい。

本構成により、第１ユーザは、ゲーム未登録の第２ユーザに対して、積極的にゲームに招待することを動機付けられる。本構成によって、ゲーム未登録者のゲームへの登録を促進することができる。

次に、ゲーム内交流を促進することができる好ましい構成について説明する。この構成の表示制御手段７８は、第１ユーザのゲーム内の複数のキャラクタの何れかと対応付けられた第２ユーザのうち、ゲームに登録済みの第２ユーザに対して、ゲーム内交流のためのゲーム内交流操作部を、第１ユーザのゲーム画面に表示させる機能を有する。ゲーム内交流操作部の一例は、図１０の画面中の挨拶ボタン２０７である。表示制御手段７８は、ゲームに未登録の第２ユーザのキャラクタに対応付けて挨拶ボタン２０７を設けた図１０の画面を表示させる画面データ（画面表示制御データ）を生成し、これを第１ユーザの端末装置３へ送信する。この画面データを受信した第１ユーザの端末装置３の表示部３５には、挨拶ボタン２０７を含む図１０の画面が表示される。

そして、本実施の形態のゲームサーバ１は、図２６に例示するように、前述の構成の他に、ゲーム内交流手段８１をさらに備えている。このゲーム内交流手段８１は、ゲーム内交流操作部を選択する操作が行われた場合に、ゲームに登録済みの前記第２ユーザに対するゲーム内交流を実行する機能を有する。本実施の形態では、第１ユーザが挨拶したい第２ユーザの挨拶ボタン２０７を押せば、ゲーム内交流手段８１が、当該第２ユーザに対して、挨拶を実行する。前述のように、挨拶を受けた側の第２ユーザは、自分の端末装置３の画面で、第１ユーザから挨拶があったことを確認することができる。

さらに、本実施の形態のパラメータ向上手段８０は、ゲーム内交流操作部を選択する操作が行われた場合に、ゲームに登録済みの前記第２ユーザと対応付けられたキャラクタのパラメータを、当該操作が行われない場合よりも向上させる機能を有する。例えば、パラメータ向上手段８０は、挨拶ボタン２０７が押された第２ユーザのキャラクタの能力を、所定ランク向上させたり、所定量または所定割合向上させたりする。

このパラメータ向上効果は、１回のゲームプレイのみ有効としてもよいし、所定期間（例えば１日間）有効としてもよい。

本構成により、第１ユーザは、ゲームに登録済みの第２ユーザに対して、積極的にゲーム内交流を行うことを動機付けられる。これにより、ゲーム内のユーザ間の交流も促進して、ゲームの活性化を図ることができる。

なお、上記の説明では、ゲーム内交流として挨拶を例示したが、メッセージの送信、プレゼント等、ゲームに登録済みのユーザ間で行われる、ゲーム内での様々な交流を適用することができる。

〔ゲーム管理装置の他の構成例〕
ゲーム管理装置の他の構成例を、図２７の機能ブロック図等を参照しながら説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。

本実施の形態のゲーム管理装置としてのゲームサーバ１は、コミュニティサービスにおける前記第１ユーザと前記第２ユーザとの間の交流度合いに基づいて、第１ユーザが利用するゲーム内の前記第２ユーザのキャラクタのパラメータを変動させる構成を有する。図２７に示すように、本ゲームサーバ１は、主に、対応付け手段７１、取得手段７２および変動手段８３を備えている。ここで、対応付け手段７１および取得手段７２は、前述の実施の形態において説明したとおりである。

なお、前述の実施の形態では、第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザを、決定手段７３が自動的に決定する構成について説明した。これに対して本実施の形態では、第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザを、前述の実施の形態と同様に決定手段７３が自動で決定する構成としてもよいし、第１ユーザが手動で第２ユーザを決定するようにしてもよい。

本実施の形態のゲームサーバ１が決定手段７３を備えた構成例を、図２８の機能ブロック図に示す。本構成により、第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザを選択する第１ユーザの手間を省くことができる。なお、決定手段７３による自動的な決定をデフォルトとし、第１ユーザによる任意の変更（手動による変更）を可能としてもよい。

前記変動手段８３は、取得手段７２によって取得されたコミュニティサービスにおける第１ユーザと第２ユーザとの間の交流度合いに基づいて、対応付け手段７１によって第２ユーザと対応付けられたキャラクタのパラメータを変動させる機能を有する。例えば、変動手段８３は、パラメータの一例としての能力を、所定ランク向上（または低下）させたり、所定量または所定割合向上（または低下）させたりする。

前述のように、第２ユーザのキャラクタのパラメータには、能力以外にも、調子、キャラクタの大きさ、色、形態、身長、体重、年齢、キャラクタの性格（積極性、攻撃性等）、ゲーム内でのキャラクタの登場頻度（回数）等、様々なパラメータが考えられる。よって、変動手段８３は、能力に代えて調子等のパラメータを変動させてもよい。あるいは、能力と調子を変動させる等、２つ以上のパラメータを変動させてもよい。

ここで、交流度合いとしては、前述のように、所定期間における交流回数、交流頻度、または交流ポイントの合計を適用することができる。特に、図１７ないし図１９に例示するように、ＳＮＳにおける第１ユーザと第２ユーザとの間の交流内容に応じた交流ポイントを適用し、交流度合いを算出することが好ましい。これにより、ＳＮＳにおける現実世界の交流内容に応じた適切な交流度合いの評価が可能となる。また、前述のように、第１ユーザから第２ユーザに対して交流が行われた場合と、第２ユーザから第１ユーザに対して交流が行われた場合とで、交流ポイントを異ならせてもよい（図１８または図１９参照）。

変動手段８３によるパラメータ変動の具体例を次に示す。例えば、変動手段８３は、第１ユーザと第２ユーザとの間の交流度合いが大きいほど、その第２ユーザと対応付けられたキャラクタのパラメータの向上率を大きくする。図２９に、交流度合いの一例としての交流ポイントと、パラメータの一例としての能力の向上率との関係の一例を示す。この例では、現在から遡る１日（または前日）の交流ポイントの合計が大きいほど、第２ユーザのキャラクタの能力向上率を大きくしている。すなわち、交流ポイントの合計が０〜１、２〜４、５〜７、８〜９、１０〜１５、１６〜２０、２１以上の場合、第２ユーザのキャラクタの能力向上率は、それぞれ０％、５％、７％、９％、１０％、１５％、２０％となる。図２９に例示する情報は、記憶手段（ＲＡＭ１３、補助記憶装置１４）に記憶されており、変動手段８３は、この情報に基づいて、第２ユーザのキャラクタの能力を変動させる。

図２９の例は、交流度合いに応じて第２ユーザのキャラクタの能力を向上させる例であるが、変動手段８３によるパラメータの変動は、パラメータを向上させることに限定されず、パラメータを低下させるものであってもよい。パラメータの低下を伴う一例としては、前記交流ポイントの合計が所定の閾値以上の場合には、閾値との差が大きいほど、第２ユーザのキャラクタの能力（または能力向上率）を大きくする一方、閾値未満の場合には、閾値との差が大きいほど、第２ユーザのキャラクタの能力（または能力向上率）を小さくする。具体例としては、前記閾値を例えば「５」とし、前記交流ポイントの合計が０〜１、２〜４、５、６〜７、８〜９、１０〜１５、１６〜２０、２１以上の場合、第２ユーザのキャラクタの能力向上率を、それぞれ−５％、−３％、０％、３％、５％、１０％、１５％、２０％とする。なお、パラメータの低下を伴う場合、低下の程度が大きくなり過ぎないように、上記の例では−５％を限界としている。

また、第１ユーザと第２ユーザとの間で、例えば、所定期間（例えば１か月）以上ＳＮＳでの交流がない等の条件を満たした場合にのみ、当該第２ユーザのキャラクタの能力を所定量（または所定割合）低下させるようにしてもよい。例えば、第１ユーザＡと第２ユーザＢとの間で、ＳＮＳでの交流がない期間が１か月以上継続された場合、第１ユーザＡのゲームにおいて第２ユーザＢのキャラクタの能力を５％低下させる。あるいは、第１ユーザＡと第２ユーザＢとの間で、ＳＮＳでの交流がない期間が１か月以上継続された場合、第１ユーザＡのゲームにおいて第２ユーザＢのキャラクタの能力を、例えば１か月毎に５％ずつ低下させるようにしてもよい。この場合、例えば最大で２０％の低下に止める等、能力低下の限界を設けてもよい。

本実施の形態の構成により、第１ユーザは、ＳＮＳにおける第２ユーザとの交流を積極的に行うように動機付けられる。このパラメータの変動は、一時的（例えば、１回のプレイのみ、１日だけ等）であるようにして、その後、変動前のパラメータに戻るようにしてもよいし、一度変動したパラメータは元に戻らないようにしてもよい。

ここで、パラメータ変動の対象となる第２ユーザのキャラクタの基本能力（変動前の基本パラメータ）について説明する。前述のように、第２ユーザのキャラクタの基本能力の設定については、第１ユーザのチーム内の全ての第２ユーザのキャラクタの能力を同一とすることができる。あるいは、前述のように、第２ユーザがゲームに登録しているか否かによって、第２ユーザのキャラクタの能力を異ならせることができる。あるいは、前述のように、ゲームに登録済みの第２ユーザのキャラクタの能力を当該第２ユーザ自身のマイキャラクタの能力とすることもできる。

あるいは、第１ユーザのゲーム内の複数のキャラクタのそれぞれには、役割に応じた基本パラメータが予め設定されているようにしてもよい。そして、変動手段８３は、ＳＮＳにおける第１ユーザと第２ユーザとの間の交流度合いに基づいて、当該第２ユーザと対応付けられたキャラクタの基本パラメータを変動させる。

本実施の形態の野球ゲームを例に挙げると、クリーンナップのキャラクタについては、その基本パラメータ（パワー等の基本能力）を他の打順のキャラクタよりも大きく設定しておく。より具体的な例としては、クリーンナップのキャラクタの基本能力をＥランクとし、打順１番および２番のキャラクタの基本能力をＦランクとし、打順６番から９番のキャラクタの基本能力をＧランクとする。なお、クリーンナップの中でも、例えば、４番打者の能力は「Ｅ５０」、３番打者の能力は「Ｅ３０」、５番打者の能力は「Ｅ１０」というように、打順によって基本能力を異ならせても良い。あるいは、全ての打順について、キャラクタの基本パラメータを異ならせてもよい。例えば、基本パラメータの大きい順に打順を並べると、４→３→５→１→２→６→７→８→９になるようにする。この場合であっても、第１ユーザのマイキャラクタについては、前述のように第１ユーザがゲームで成長させた能力が適用されるようにすることができる。

この場合、クリーンナップのキャラクタのパラメータの向上は、高い基本パラメータをベースとすることになるので、実質的に、他のキャラクタよりも高いパラメータの向上を見込めることになる。従って、第１ユーザはゲームを有利に運ぶためには、クリーンナップ（特に、４番打者）のキャラクタに対応付けられた第２ユーザと、ＳＮＳでより多くの交流をするといった戦略をとれる。あるいは逆に、普段からＳＮＳでの交流が多い第２ユーザをクリーンナップのキャラクタに対応付けるようにしてもよい。本構成により、ＳＮＳでの交流がゲーム戦略に及ぼす影響がより大きくなり、ゲームの興趣性をより高めることができる。

なお、上記では、キャラクタの役割として打順を例に挙げたがこれに限定されない。例えば、キャラクタの役割の他の例としてのポジションによって、基本パラメータを異ならせてもよい。

また、図３０に例示するように、ゲームサーバ１は、取得手段７２によって取得された、ＳＮＳにおける第１ユーザと第２ユーザとの間の交流度合いに基づいて、当該第２ユーザと対応付けられたキャラクタの役割を決定する役割決定手段７４をさらに備えている構成とすることができる。

この役割決定手段７４は、前述の実施の形態で説明した通りであり、例えば、交流度合いが大きい第２ユーザと対応付けられたキャラクタを、クリーンナップまたは上位打線に自動的に設定する。これにより、ＳＮＳで第１ユーザと多く交流している第２ユーザのキャラクタほど、打順がクリーンナップに移動されるので、第１ユーザにとって親しい友達のキャラクタほど、高い能力が設定される。但し、一旦クリーンナップに設定された第２ユーザのキャラクタであっても、第１ユーザとその第２ユーザとのＳＮＳを利用した現実世界での交流が少なくなると、その第２ユーザのキャラクタの役割（打順）は、自動的に下位打線に変更される。さらに、ＳＮＳでの交流が少なくなると、その第２ユーザのキャラクタは、スタメンからも外れる。なお、スタメンからも外れた第２ユーザのキャラクタは、ベンチ入りの控えキャラクタとなる（すなわち、第２ユーザは控えキャラクタに対応づけられる）ようにしてもよい。

本実施の形態の構成により、第１ユーザがＳＮＳでよく交流している第２ユーザのキャラクタが、自動的に、第１ユーザの利用するゲーム内で重要な役割を担うようにすることができる。よって、第１ユーザにとっては、ゲームを通して、ＳＮＳでよく交流している親しい第２ユーザとのつながりを、より強めることができる。

また、図３１に例示するように、ゲームサーバ１は、前述の構成の他に、プロフィール情報取得手段７５をさらに備えている構成とすることができる。このプロフィール情報取得手段７５は、前述の実施の形態で説明した通りであり、ＳＮＳにおいて第２ユーザが登録しているプロフィール情報を取得する機能を有する。例えば、プロフィール情報には、年齢、性別、趣味の少なくとも１つの情報が含まれる。

そして、本実施の形態の変動手段８３は、前記交流度合い及び前記プロフィール情報に基づいて、第２ユーザと対応付けられたキャラクタのパラメータを変動させる機能を有する。

例えば、本実施の形態の野球ゲームにおいて、女性、子供（所定以下の年齢）、高齢者（所定以上の年齢）の第２ユーザに対応付けられたキャラクタについては、パラメータのパワーの値を本来の値よりも低下させる一方、ミートの値を本来の値よりも向上させる。これにより、ボールには当て易いが、長打にはなり難いようにする。あるいは、単純にパラメータのパワーの値を本来の値よりも低下させるだけでもよい。また、スポーツを趣味としている第２ユーザに対応付けられたキャラクタについては、パラメータのパワー、ミート等の値を本来の値よりも向上させるようにしてもよい。

上記のようにして、変動手段８３は、第２ユーザのプロフィール情報にもとづいて、第２ユーザのキャラクタの基本パラメータを調整し、その後、当該第２ユーザについての交流度合い基づいて、さらにパラメータを調整することができる。あるいは、変動手段８３は、交流度合いに基づいて第２ユーザのキャラクタのパラメータを調整し、その後、第２ユーザのプロフィール情報に基づいて、さらにパラメータを調整してもよい。

このように、ＳＮＳにおいて第２ユーザが登録している現実世界の年齢等の情報に基づいて、その第２ユーザに対応付けられたキャラクタのパラメータを変化させることにより、現実世界の第２ユーザの特定の属性を、第１ユーザが利用するゲーム内の第２ユーザのキャラクタに反映させることができ、ゲームの興趣性を高めることができる。

また、前述の実施の形態で説明したように、前記役割決定手段７４が、前記交流度合い及び前記プロフィール情報に基づいて、第２ユーザと対応付けられたキャラクタの役割（打順、ポジション等）を自動的に決定する構成を採用してもよい。

ここで、第１ユーザが野球ゲームを遊戯する場合のゲームサーバ１の動作例を説明する。図３２は、第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザを、ゲームサーバ１が自動的に決定する場合の動作例を示すフローチャートである。

図３２のフローチャートは、前述の図２２のフローチャートのステップＳ８とＳ９との間に、ステップＳ１１を追加したものであり、その他のステップは図２２のフローチャートと同様である。ステップＳ１１では、ステップＳ３にて算出された第１ユーザと第２ユーザとの間の交流度合い（例えば前日の交流ポイントの合計）に基づいて、ゲームサーバ１が、各第２ユーザのキャラクタの基本能力を変動させる。例えば、ゲームサーバ１は、図２９に示す、交流ポイントと能力向上率との関係に基づいて、各第２ユーザのキャラクタの能力向上率を決定する。そして、ゲームサーバ１は、決定した能力向上率に従って、各第２ユーザのキャラクタの基本能力を変動させる。変動後の各キャラクタの能力および能力向上率は、図２０に例示する第１ユーザのゲーム内キャラクタに関する情報として記憶される。なお、図２０では省略しているが、能力向上率の情報も記憶される。

その後、ゲームサーバ１は、図２０に例示する第１ユーザのゲーム内キャラクタに関する情報に基づいて、例えば図３３に示すスタメン発表画面のデータを生成し（Ｓ９）、第１ユーザの端末装置３に送信する（Ｓ１０）。このとき、ゲームサーバ１は、画面のデータと共に、第１ユーザのゲーム内キャラクタに関する情報も併せて送信する。これにより、第１ユーザの端末装置３には、図３３に例示するスタメン発表画面が表示される。

図３３のスタメン発表画面には、第２ユーザのキャラクタの能力向上率の情報２１１が表示される。よって、第１ユーザは、ＳＮＳにおける第２ユーザとの交流度合いが、第２ユーザのキャラクタに反映されていることを認識できる。なお、図３３の画面では、便宜上、前述のロックボタン２０５（図６参照）、招待ボタン２０６（図１０参照）、挨拶ボタン２０７（図１０参照）等を省略しているが、これらのボタンを設けてもよい。

また、図３３の画面において、第１ユーザが、第２ユーザのキャラクタの画像２０１またはキャラクタ名２０２を選択（例えばクリック操作）すれば、当該第２ユーザのキャラクタの詳細な能力（パワー、ミート等の個別能力）の情報や、当該第２ユーザのＳＮＳのプロフィール情報等を表示する画面に遷移するようにしてもよい。この画面のデータは、ゲームサーバ１から第１ユーザの端末装置３へ提供される。

その後、第１ユーザは、プレイボタン２１０を押して、各キャラクタを使用した打撃を開始してもよいし、その前に、キャラクタに対応付けられた第２ユーザを変更したり、キャラクタの打順を入れ替えたりしてもよい。もしも第１ユーザによって、キャラクタに対応付けられた第２ユーザが手動で変更された場合には、ゲームサーバ１は、第１ユーザと変更後の第２ユーザとの間の交流度合いを取得する。そして、ゲームサーバ１は、取得した交流度合いに基づいて、変更後の第２ユーザのキャラクタの基本能力を変動させ、スタメン発表画面を更新する。

なお、図３２のフローチャートには、第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザを、ゲームサーバ１が自動的に決定する場合の動作例を示したが、第１ユーザがゲーム内キャラクタに対応付けられる第２ユーザを一から手動で設定する（打順、ポジション等も手動で設定）することも可能である。この場合、ゲームサーバ１は、前述のステップＳ２、Ｓ３、Ｓ８、Ｓ１１を実行し、第１ユーザが手動で設定した第２ユーザのキャラクタの能力を、交流度合いに基づいて設定することができる。

本実施の形態の構成では、ＳＮＳおける第１ユーザと第２ユーザとの交流度合いが評価されて、第１ユーザの利用するゲームにおいて、第２ユーザと対応付けられたキャラクタのパラメータが自動的に調整される。すなわち、ＳＮＳにおける第１ユーザと第２ユーザとの交流が、第１ユーザのゲームに反映される。本構成により、第１ユーザは、ゲームを通しても、第２ユーザとのつながりを強め、延いてはゲームに対する関心と興味をより強める結果となる。よって、本ゲーム管理装置は、第１ユーザにとって飽きのこない継続性を有するゲームサービスの提供を実現できる。

前述のように本構成では、第１ユーザと第２ユーザとの交流度合いに基づいて、第２ユーザのキャラクタのパラメータが自動的に変動する。この場合、以下の（Ａ）〜（Ｃ）に例示するように、現実世界に起因する不確定要素が存在するために、第１ユーザは、自分の意思でいつでも、どの第２ユーザのキャラクタのパラメータを変動させることが出来るわけではないし、また、第１ユーザの意思に関わらず、ある第２ユーザのキャラクタのパラメータが変動することもある。これがゲームの面白さを増加させる。

（Ａ）第１ユーザが相手（第２ユーザ）と通話をするためには、まず相手につながる必要があるが、相手が電話に出られず通話できない場合があり得る（相手が電車、自動車等に乗って移動中、他者と通話中、仕事中等）。

（Ｂ）第２ユーザによってはプライベート上の特別な事情があり、第１ユーザがその事情を知っているため当該第２ユーザと交流し難い場合があり得る（仕事が多忙、慶弔関連の事由がある等）。

（Ｃ）第１ユーザの方から交流をしなくとも、ある第２ユーザから電話やメールが来ることによって、期せずして当該第２ユーザのキャラクタの能力向上に寄与する場合もあり得る。

次に、第１ユーザのゲーム内キャラクタに対応付けられた第２ユーザの中に、所定条件を満たす第２ユーザが複数いる場合に、第１ユーザのゲームで特殊効果を発生させる好ましい構成について説明する。この構成のゲームサーバ１は、図３４に例示するように、前述の構成の他に、特殊効果発生手段８４をさらに備えている。この特殊効果発生手段８４は、複数の第２ユーザの少なくとも一部のそれぞれと対応付けられたキャラクタの中に、ＳＮＳにおいて第２ユーザ同士が前記所定の関係を有している２以上のキャラクタが存在する場合に、ゲーム上の特殊効果を発生させる機能を有する。

ここで、前記所定の関係とは、前述のようにＳＮＳ等のコミュニティサービスにおいてユーザ間で交流可能となる関係であればよく、例えばＳＮＳのチャットルーム内のメンバの関係等も含まれる。

例えば、図３３において、第１ユーザのゲーム内キャラクタに対応付けられた第２ユーザとしての友達Ｂおよび友達Ｃが、ＳＮＳで交流可能となる所定の関係を有している場合、特殊効果発生手段８４は、第１ユーザＡのゲームにおいて、ゲーム上の特殊効果を発生させる。例えば、特殊効果として、友達Ｂおよび友達Ｃにそれぞれ対応付けられているキャラクタの能力を一時的（例えば、１回のプレイのみ、１日だけ等）に１０％向上させる。この場合の特殊効果による能力向上は、前述の交流度合いに基づく能力向上に上乗せされる。

なお、特殊効果は、パワー等の能力の向上に限らず、キャラクタに新たな特殊能力（例えば、バットスイングが早くなる能力）を追加したり、キャラクタに装備する特殊アイテム（バット、スパイク、グローブ等）を付与したりするものであってもよい。例えば、ホームランが出易いバットがキャラクタに装備された場合、第１ユーザが当該キャラクタを使用して打撃を行えば、ボールオブジェクトの飛距離が１０％伸びて、ホームランになる確率が高まる。

また、ゲームサーバ１は、第１ユーザに特殊効果の発生を報知することが好ましい。例えば、図３３の友達Ｂおよび友達Ｃが所定の関係を有する場合、友達Ｂのキャラクタおよび友達Ｃのキャラクタが打席に立ったときに（あるいはボールを打撃したときに）、当該キャラクタが光る、画面の色が変化する、効果音（声援等）が鳴る、等の効果演出が発生し、第１ユーザに特殊効果の発生が報知される。

なお、上記では図３３の画面の友達Ｂおよび友達Ｃが所定の関係である例を示したが、友達Ｂおよび友達Ｄが所定の関係であっても、ゲーム上の特殊効果が発生する。

また、３人以上の第２ユーザ（例えば図３３の友達Ｂ、Ｃ、Ｄ…）が、ＳＮＳにおいて互いに前記所定の関係である場合も、第１ユーザＡのゲームにおいて、ゲーム上の特殊効果が発生する。

第１ユーザＡにとって、ゲーム内キャラクタに対応づけられた第２ユーザ（友達Ｂ、Ｃ、Ｄ…）は、ＳＮＳで交流する現実世界の友達等の関係である。よって、第１ユーザＡは、例えば友達Ｂ、Ｃ同士がＳＮＳで交流可能な所定の関係であるか否かは知っていることが多い。従って、第１ユーザＡはゲームを有利に運ぶためには、所定の関係を有する２人以上の第２ユーザを、自分のゲーム内キャラクタに対応付けるという戦略をとれる。本構成により、ゲームの興趣性をより高めることができる。

また、本実施の形態の野球ゲームのように、複数のキャラクタのプレイ順序を予め定めることができるゲームにおいては、特殊効果の発生条件を、所定の関係を有する２人以上の第２ユーザのキャラクタを、連続したプレイ順序に配置することとしてもよい。この場合、特殊効果発生手段８４は、複数の第２ユーザの少なくとも一部のそれぞれと対応付けられたキャラクタの中に、ＳＮＳにおいて第２ユーザ同士が前記所定の関係を有している２以上のキャラクタが存在し、且つ、当該２以上のキャラクタが連続したプレイ順序に配置されている場合に、ゲーム上の特殊効果を発生させる機能を有する。

例えば、図３３の画面において、友達Ｂおよび友達Ｃが所定の関係であれば、友達Ｂのキャラクタ（２番打者）および友達Ｃのキャラクタ（３番打者）の打順が連続しているので、特殊効果が発生する。

一方、図３３の画面において、友達Ｂおよび友達Ｄが所定の関係であったとしても、友達Ｂのキャラクタ（２番打者）および友達Ｄのキャラクタ（４番打者）の打順が連続していないので、特殊効果が発生しない。

あるいは、前述のように、対象となる前記２以上のキャラクタのプレイ順序が連続していない場合でも特殊効果が発生するようにしてもよいが、プレイ順序が連続している場合の方が、プレイ順序が連続していない場合よりも大きな特殊効果が発生するようにすることが好ましい。

本構成により、第１ユーザは、ゲームを有利に運ぶために、ＳＮＳにおいて第２ユーザ同士が所定の関係を有している２以上のキャラクタを、連続したプレイ順序に配置するという戦略をとれる。本構成により、ゲームの興趣性をより高めることができる。

なお、本構成は、野球ゲームに限らず、複数のキャラクタのプレイ順序を予め定めることができるゲームであれば適用可能である。

また、特殊効果発生手段８４は、対象となる前記２以上のキャラクタのプレイ順序の連続が長くなるほど、前記特殊効果をより大きくすることが好ましい。

例えば、図３３の画面において、友達Ｂおよび友達Ｃの２人が所定の関係である場合よりも、友達Ｂ、友達Ｃ、友達Ｄの３人が所定の関係である方が、特殊効果は大きくなる。例えば、前者の特殊効果が対象となる２つのキャラクタの能力を１０％向上させるものであるに対して、後者の特殊効果は対象となる３つのキャラクタの能力を１０％（あるいは１５％等であってもよい）向上させるものである。

ところで、図３３の画面において、キャラクタの打順が３連続する友達Ｂ、友達Ｃ、友達Ｄの３人が所定の関係を満たす条件としては、以下の（ａ）または（ｂ）の何れの条件を適用してもよい。

（ａ）友達Ｂ、友達Ｃ、友達Ｄの３人のそれぞれが、他の２人と所定の関係を有している。つまり、「友達Ｂと友達Ｃ」、「友達Ｂと友達Ｄ」、「友達Ｃと友達Ｄ」が、それぞれ所定の関係を有している。

（ｂ）キャラクタの打順が連続する「友達Ｂと友達Ｃ」および「友達Ｃと友達Ｄ」が、それぞれ所定の関係を有していれば、キャラクタの打順が直接的には連続しない「友達Ｂと友達Ｄ」は所定の関係を有していなくてもよい。

対象となるキャラクタのプレイ順序がｎ連続（ｎは３以上の整数）する場合も、上記の（ａ）または（ｂ）と同様の条件を適用できる。

本実施の形態の構成によれば、第１ユーザはゲームを有利に運ぶためには、ＳＮＳにおいて第２ユーザ同士が所定の関係を有している２以上のキャラクタのプレイ順序（野球ゲームの場合打順）の連続をできるだけ長くするという戦略をとれる。本構成により、ゲームの興趣性をより高めることができる。

〔ゲームシステムの他の構成例〕
サーバと端末装置とは互いに通信して各種データの送受が可能であり、共にＣＰＵ、ＲＯＭ、ＲＡＭ、補助記憶装置、通信制御部等を備えた情報処理装置（コンピュータ）であって、同様のハード構成を有する。よって、サーバと端末装置とを含むゲームシステムにおいて、上述の各実施の形態で説明したゲーム管理装置が具備する各手段は、サーバ又は端末装置の何れか一方が備えていればよい。すなわち、ゲーム管理装置は、互いに通信して各種データの送受を行うサーバおよび端末装置に設けられる構成とすることができ、前述の実施の形態と同様の作用効果を奏する。

例えば、図１４ではゲームサーバ１が、対応付け手段７１、取得手段７２および決定手段７３を備えていたが、図３５に例示するように、各手段の機能をサーバおよび端末装置の何れかに持たせることが可能である。ここで、図３５に示すサーバ５０１のハード構成は、図４に示したゲームサーバ１と同様であり、端末装置５０３のハード構成は、図５に示した端末装置３と同様である。図３５には、サーバ５０１に取得手段７２を設けると共に、端末装置５０３に対応付け手段７１および決定手段７３を設ける構成例を示している。なお、図３５はゲームシステムの構成の一例であり、他の構成も可能である。

また、図３６に示すように、端末装置５０３が、対応付け手段７１、取得手段７２および決定手段７３を備えている構成とすることもできる。すなわち、ゲーム管理装置をゲーム端末である端末装置５０３それ自体に実装することができ、この場合も前述の実施の形態と同様の作用効果を奏する。この場合、サーバ５０１が、ＳＮＳサーバ１０１との間の通信を中継したり、各ユーザのゲーム情報を管理したり、端末装置５０３間で行われる挨拶やメッセージの送受等のサービスをユーザに提供したりするが、その他の処理は全て端末装置５０３側で実行されるようにすることができる。あるいは、各ユーザのゲーム情報の管理も、各ユーザの端末装置５０３側で行うこともできる。

また、例えば、図２７ではゲームサーバ１が、対応付け手段７１、取得手段７２および変動手段８３を備えていたが、図３７に例示するように、各手段の機能をサーバおよび端末装置の何れかに持たせることが可能である。ここで、図３７に示すサーバ５０１のハード構成は、図４に示したゲームサーバ１と同様であり、端末装置５０３のハード構成は、図５に示した端末装置３と同様である。図３７には、サーバ５０１に取得手段７２を設けると共に、端末装置５０３に対応付け手段７１および変動手段８３を設ける構成例を示している。なお、図３７はゲームシステムの構成の一例であり、他の構成も可能である。また、図３８に示すように、端末装置５０３が、対応付け手段７１、取得手段７２および変動手段８３を備えている構成とすることもできる。すなわち、ゲーム管理装置をゲーム端末である端末装置５０３それ自体に実装することができ、この場合も前述の実施の形態と同様の作用効果を奏する。

また、前述の各手段７４〜８１、８４等についても、サーバ側だけではなく、端末装置（ゲーム端末）側に設けることもできる。

〔その他の実施の形態〕
前述の実施の形態では、取得手段７２が、コミュニティサービスにおける第１ユーザと第２ユーザとの間の交流度合いを取得し、決定手段７３が、その交流度合いに基づいて、第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザを決定する構成について説明したが、以下のようなバリエーションも可能である。

すなわち、決定手段７３は、コミュニティサービスにおいて第１ユーザが第２ユーザと所定の関係を構築した順序または時間（日付、日時等）に基づいて、第１ユーザのゲーム内キャラクタに対応付けられる第２ユーザを決定してもよい。ここで、第１ユーザが第２ユーザと所定の関係を構築した順序または時間とは、例えば、コミュニティサービスにおいて、第１ユーザによって第２ユーザが（または第２ユーザによって第１ユーザが）友達登録された順序または友達登録された時間を適用することができる。

例えば、決定手段７３は、第１ユーザによって最も早く友達登録された第２ユーザから順に、複数のキャラクタにそれぞれ対応付ける所定人数（本実施の形態では９人）の第２ユーザを選択する。あるいは、決定手段７３は、逆に、最も新しく（遅く）友達登録された第２ユーザから遡って９人を選択してもよい。友達登録が早い順に第２ユーザを選択する態様は、第１ユーザとの交流期間の長さを評価して、キャラクタに対応付ける第２ユーザを決定するものである。一方、友達登録が新しい順に第２ユーザを選択する態様は、交流の新鮮さを評価して、キャラクタに対応付ける第２ユーザを決定するものである。

また、前述の実施の形態では、複数のキャラクタのそれぞれに複数の第２ユーザを対応付ける構成について説明したが、第１ユーザが利用するゲームにおいて、第２ユーザを対応付けるキャラクタが１つだけである構成としてもよい。この場合、決定手段７３は、キャラクタに対応付けられる第２ユーザを１人だけ決定することになる。

また、各種情報を記憶装置に記憶する記憶制御機能を有する構成（ユーザ情報記憶制御手段６０など）に関し、記憶装置そのものについては当該構成に含まれないので、ゲーム管理装置（またはゲームシステム）の内外を問わず、どこに設置されていてもよい。例えば、記憶装置は、ゲームサーバ１が有するＲＡＭ１３や補助記憶装置１４、データベースサーバ２、端末装置３が有するＲＡＭ３３や補助記憶装置３９、あるいはゲーム管理装置や端末装置とは別構成のファイルサーバ（オンラインストレージ）等であってもよい。

また、前述の各実施の形態で説明した各構成は、適宜組み合わせて適用することができる。

また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等）、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてサーバ、端末装置（ゲーム端末）のＣＰＵにより実行される。また、プログラムをサーバ等に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。

１ ゲームサーバ（ゲーム管理装置）
２ データベースサーバ（ゲーム管理装置）
３ 端末装置
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 補助記憶装置
７１ 対応付け手段
７２ 取得手段
７３ 決定手段
７２ａ 交流情報取得手段
７２ｂ 交流度合算出手段
７４ 役割決定手段
７５ プロフィール情報取得手段
７６ 通知手段
７７ パラメータ管理手段
７８ 表示制御手段
７９ 招待情報通知手段
８０ パラメータ向上手段
８１ ゲーム内交流手段
８３ 変動手段
８４ 特殊効果発生手段
２０６ 招待ボタン（招待操作部の一例）
２０７ 挨拶ボタン（ゲーム内交流操作部の一例）
５０１ サーバ（ゲーム管理装置、ゲームシステム）
５０３ 端末装置（ゲーム管理装置、ゲームシステム）

Claims (18)

1. 第１ユーザと、当該第１ユーザと所定の関係がある複数の第２ユーザのそれぞれとの間で交流が可能なコミュニティサービスと連携してゲームを進行させるゲーム管理装置であって、
   前記第１ユーザが登録して利用する前記ゲームにおける複数のキャラクタに、前記複数の第２ユーザの少なくとも一部をそれぞれ対応付ける対応付け手段と、
   前記コミュニティサービスにおける前記第１ユーザと前記第２ユーザとの間の交流度合いを取得する取得手段と、
   前記交流度合いに基づいて、前記第２ユーザと対応付けられたキャラクタのパラメータを変動させる変動手段と、を備え、
   前記対応付け手段は、前記複数のキャラクタにそれぞれ対応付ける前記第２ユーザとして、前記ゲームに登録済みの前記第２ユーザおよび前記ゲームに未登録の前記第２ユーザを含め、
   前記複数のキャラクタの何れかと対応付けられた前記第２ユーザのうち、前記ゲームに未登録の前記第２ユーザに対して、前記ゲームに招待するための招待操作部を、前記第１ユーザが遊戯中の前記ゲームにおける前記複数のキャラクタの一覧画面の中に、前記ゲームに未登録の前記第２ユーザと対応付けられた前記キャラクタと対応させて表示させる表示制御手段をさらに備えているゲーム管理装置。
2. 前記招待操作部を選択する操作が行われた場合に、前記ゲームに未登録の前記第２ユーザと対応付けられたキャラクタのパラメータを、当該操作が行われない場合よりも向上させるパラメータ向上手段をさらに備えている請求項１に記載のゲーム管理装置。
3. 前記対応付け手段によって前記ゲームに登録済みの前記第２ユーザと対応付けられたキャラクタのパラメータを、前記ゲームに未登録の前記第２ユーザと対応付けられたキャラクタのパラメータよりも大きくするパラメータ管理手段をさらに備えている請求項１または２に記載のゲーム管理装置。
4. 前記取得手段は、前記コミュニティサービスにおける前記第１ユーザと前記第２ユーザとの間の交流内容に応じた交流ポイントによって前記交流度合いを算出する請求項１ないし３の何れか１項に記載のゲーム管理装置。
5. 前記第１ユーザから前記第２ユーザに対して交流が行われた場合と、前記第２ユーザから前記第１ユーザに対して交流が行われた場合とで、前記交流ポイントを異ならせる請求項４に記載のゲーム管理装置。
6. 前記複数のキャラクタのそれぞれには、役割に応じた基本パラメータが予め設定されており、
   前記変動手段は、前記交流度合いに基づいて、前記第２ユーザと対応付けられた前記キャラクタの前記基本パラメータを変動させる請求項１ないし５の何れか１項に記載のゲーム管理装置。
7. 前記交流度合いに基づいて、前記第２ユーザと対応付けられた前記キャラクタの前記役割を決定する役割決定手段をさらに備えている請求項６に記載のゲーム管理装置。
8. 前記コミュニティサービスにおける前記第２ユーザのプロフィール情報を取得するプロフィール情報取得手段をさらに備え、
   前記変動手段は、前記交流度合い及び前記プロフィール情報に基づいて、前記第２ユーザと対応付けられた前記キャラクタのパラメータを変動させる請求項１ないし７の何れか１項に記載のゲーム管理装置。
9. 前記プロフィール情報には、年齢、性別、趣味の少なくとも１つの情報が含まれる請求項８に記載のゲーム管理装置。
10. 前記複数の第２ユーザの少なくとも一部のそれぞれと対応付けられた前記キャラクタの中に、前記コミュニティサービスにおいて前記第２ユーザ同士が前記所定の関係を有している２以上のキャラクタが存在する場合に、ゲーム上の特殊効果を発生させる特殊効果発生手段をさらに備えている請求項１ないし９の何れか１項に記載のゲーム管理装置。
11. 前記ゲームは、前記複数のキャラクタのプレイ順序を予め定めることができるゲームであり、
    前記複数の第２ユーザの少なくとも一部のそれぞれと対応付けられた前記キャラクタの中に、前記コミュニティサービスにおいて前記第２ユーザ同士が前記所定の関係を有している２以上のキャラクタが存在し、且つ、当該２以上のキャラクタが連続したプレイ順序に配置されている場合に、ゲーム上の特殊効果を発生させる特殊効果発生手段をさらに備えている請求項１ないし９の何れか１項に記載のゲーム管理装置。
12. 前記特殊効果発生手段は、前記２以上のキャラクタのプレイ順序の連続が長くなるほど、前記特殊効果をより大きくする請求項１１に記載のゲーム管理装置。
13. 前記交流度合いに基づいて、前記複数の第２ユーザの中から、前記対応付け手段によって前記複数のキャラクタに対応付けられる前記第２ユーザを決定する決定手段をさらに備えている請求項１ないし１２の何れか１項に記載のゲーム管理装置。
14. 前記コミュニティサービスにおける前記交流とは、前記第１ユーザと前記第２ユーザとの間で、ネットワークを介して、文字情報、画像情報または音声情報が、一方的にまたは相互に伝達されることである請求項１ないし１３の何れか１項に記載のゲーム管理装置。
15. ユーザが操作するゲーム端末装置と通信可能なサーバとして構成される請求項１ないし１４の何れか１項に記載のゲーム管理装置。
16. 請求項１ないし１４の何れか１項に記載のゲーム管理装置の各手段を備えた、ユーザが操作するゲーム端末装置。
17. 請求項１ないし１４の何れか１項に記載のゲーム管理装置の各手段を、相互に通信するサーバ又は端末装置のいずれか一方が備えるゲームシステム。
18. コンピュータを請求項１ないし１４の何れか１項に記載のゲーム管理装置として動作させるためのプログラムであって、前記コンピュータを前記ゲーム管理装置が備えている各手段として機能させるためのプログラム。

Images