本発明の実施例を説明する前に、まず、本発明の概要を述べる。本発明は、ネットワークを介して行われる複数ユーザによるネットワークゲームにおいて、同時に開始されるゲームにおけるチームを決める際のマッチング処理に関するものである。
従来のマッチング処理においては、ゲームへの参加表明が他の参加ユーザより遅かった場合、その参加ユーザはそれを認識してしまうことにより、そのゲームに対して主体的に積極性を持って貢献しようという意識が阻害され、ゲームが白熱しづらくなるといった課題があった。
本発明においては、以上の課題を解消しており、ゲームへの参加表明の先後にかかわらず、最初に参加を表明したユーザであるとしてマッチング処理を行うことによって、それぞれの参加ユーザの興趣性を高めるものであり、もって、白熱したネットワークゲーム環境を提供できるものである。
ここで、ソーシャルゲームについて簡単に説明する。ソーシャルゲームとは、一般的にSNS情報を用いてウェブブラウザ上で動作するAPI(Application Programming Interface)等のプラットフォームを用い、これを基盤として動作するアプリケーションゲームソフトを言う。以下では、単にブラウザゲームと称する。
また、ソーシャルゲームには、SNS情報を用いるが、ユーザが操作する各端末装置にアプリケーションプログラムをダウンロードし、各端末装置内でアプリケーションプログラムが実行され、各端末装置とサーバ装置との間では各種のパラメータを送受信して行うものもある。以下では、単にアプリゲームと称する。
なお、本発明の一例である以下の処理は、ブラウザゲームとしてゲームを提供するサーバ装置において処理することも可能であるし、アプリゲームとして端末装置側で実行されるプログラムにて処理することも可能である。また、以下で説明する例は、本発明の理解のためのものであり、本発明の技術的範囲がこれに限定されるものではない。
まず、実施例1について説明する。図1は、本発明の実施例1にかかるソーシャルゲームシステム100を示す図である。ソーシャルゲームシステム100は、サーバ装置10と、サーバ装置10と基地局40とを有線回線で接続するネットワーク30と、基地局40で代表される第1基地局40a〜第3基地局40cと、モバイル端末50で代表される第1モバイル端末50a〜第3モバイル端末50cと、PC端末70とを含む。
なお、図示の都合上、基地局40、モバイル端末50は共に3台のみ図示したが、これにかぎらず、それ以上の基地局40、モバイル端末50が存在してもよい。PC端末70についても同様である。また、第1モバイル端末40a〜第3モバイル端末40cは、それぞれ異なる基地局40と接続されるとして図示しているが、これにかぎらず、1つの基地局40に複数のモバイル端末50が接続されていても、本発明が適用可能であることは言うまでもない。
サーバ装置10は、ソーシャルゲームサービスを実施、提供するための装置である。サーバ装置10は、ネットワーク30と基地局40とを介して、モバイル端末50やPC端末70との間で、ゲーム処理のための通信処理を実行する。なお、以下においては、説明を簡易にするため、単に、「サーバ装置10とモバイル端末40ないしPC端末70との間で通信処理を実行する」などと表現し、ネットワーク30および基地局40を介する点については記載を省略する。また、以下においては、モバイル端末50やPC端末70を総称して、ユーザ端末と表現することもある。また、サーバ装置10とは、ネットワークゲームにかかるサービスを提供するプラットフォームであってもよいし、あるいは、ネットワークゲームのアプリケ―ションを提供するサーバであってもよい。
図2は、図1のサーバ装置10の構成例を示す図である。このサーバ装置10は、サーバ通信部12と、ユーザ情報管理部13と、ゲーム管理部14と、マッチング処理部15と、画像生成部16と、サーバメモリ17とを含む。
サーバ通信部12は、ネットワーク30を介して外部のSNSサーバ装置やユーザ端末等と通信する。なお、SNSサーバ装置は、サーバ装置10が兼ねてもよいこととし、SNSサーバ装置を不図示としている。
ユーザ情報管理部13は、SNSに登録されたユーザ情報をSNSサーバ装置から取得するとともにソーシャルゲームに登録したユーザの情報をサーバメモリ17にて管理する。また、ユーザ情報管理部13は、SNSサーバ装置から取得した情報を含むユーザの情報をサーバメモリ17にアップロードする。サーバメモリ17は、ユーザの情報のほかカードを用いたネットワークゲームで使用されるカード管理データなどを記憶する。
ユーザの情報は、ユーザ識別情報、ユーザ名、アバター、ユーザが入力したコメントの何れか一つ又はこれらの組み合わせとなる。これらのユーザの情報は、後述する画像生成部16においてマッチングルームの画像を生成する際に用いられて、一のユーザが他のユーザを視認しやすく臨場感を高めることができるような画像が生成されることとなる。
図3は、図2のサーバメモリ17において管理されるユーザ管理データの一例を示す図である。図3に例示するごとく、ユーザ情報管理部13は、サーバメモリ17においてテーブル状のデータを有するようにしてもよい。ここで、ユーザ名は、SNS上のユーザ名を用いられてもよいし、また、ゲームごとに設定されたユーザの名前でもよい。
また、ユーザ識別情報は、ユーザを識別するためのユニークコードである。また、レベルは、ゲームに参加した回数や得られた経験ポイントに基づき順次増加するユーザのレベルである。また、進行状況は、各ユーザがどこまでゲームを進行させているかを示す情報である。また、保有カード識別情報は、チームバトル等で用いるキャラクタカード等各種のカード識別情報である。
図4は、図2のサーバメモリ17において管理しているカード管理データの一例を示す図である。図4に例示するごとく、サーバメモリ17は、カード管理データとしてテーブル状のデータを有するようにしてもよい。ここで、図4中、名称は、カード自体、あるいはカードに表示されたキャラクタの名称を示す。レアリティ値は、そのカードの希少価値の度合いを示し、例えば、コモン、アンコモン、レア、スーパーレアのように段階的に希少度が上がるようにランク分けされている。初期攻撃値は、チームバトルにおけるキャラクタの初期の攻撃値であり、初期体力値はチームバトルにおけるキャラクタの体力の初期値である。これらは初期値であるため、バトルを繰り返し、キャラクタが進化、強化されるごとに値が変化する。
図2に戻る。ゲーム管理部14は、ソーシャルゲームの進行、クエストの管理等各種の処理・管理を行う。ゲーム管理部14は、ゲームの進行を制御し、サーバメモリ17に記憶されたユーザ情報やカード管理データにアクセスし、所定の処理を実行する。
マッチング処理部15は、ユーザ端末からクエストが選択されチームバトルへの参加要求がなされた際に、選択されたクエストに基づきユーザのチーム割り当てを行うとともに、マッチング情報を生成する。マッチング処理部15は、サーバ通信部12経由で参加要求を受け付けたユーザごとのユーザ情報を統合して、同時期に開始される同一のネットワークゲームに参加するユーザ同士のマッチング情報を生成する。さらに、マッチング処理部15は、サーバ通信部12を介して、参加要求を受け付けたそれぞれのユーザ端末に対して、生成したマッチング情報を通知する。
このとき、各ユーザ端末に送信されるマッチング情報は、参加要求をしたユーザ端末毎に異なったものとなる。たとえば、複数のユーザ端末において、同時期に開始される同一のネットワークゲームに参加要求をしたような場合、マッチング処理部15は、参加要求の順序にかかわらず、通知先のユーザ端末がもっとも早く参加要求をしたかのごとく示されるように、通知先の端末装置ごとに異ならせて、マッチング情報を生成する。「もっとも早く参加要求をしたかのごとく示される」とは、本来の参加順序にかかわらず、1番目の参加者として示すことを含む。たとえば、参加順位情報を強制的に1番に設定してもよく、また、マッチング情報内のユーザ情報の並び順が常に先頭になるように設定してもよい。
また、このマッチング情報を2段階に分けて生成あるいは通知することによって、ユーザ端末における参加ユーザの情報の表示にタイミング差を設けてもよい。このような態様により、それぞれの参加ユーザの各々に対して、それぞれの参加タイミングによらず、自らが最初の参加ユーザであると認識させることができる。詳細は後述することとする。
また、マッチング処理部15は、マッチング情報に対して、通知先の端末のユーザ情報を第1位とした参加順位情報を含め、第2位以降を通知先以外の端末のうち参加順序の早い順にユーザ情報を含めてもよい。この参加順位情報は、端末での表示順序を指し示してもよい。これにより、複数回にわたってマッチング情報を送信せずとも、参加順位情報が含まれたマッチング情報を1回のみ送信することで、前述と同様の効果を奏することができる。
また、マッチング情報は、マッチングされたユーザの情報からなり、マッチング画像そのものであってもよいが、本実施例では、別途画像生成部16を用いてマッチング画像として待合室を想定したマッチングルームの画像を生成するようにしている。マッチング処理部15は、マッチング情報を画像生成部16に出力する。
画像生成部16は、マッチング処理部15から出力されたマッチング情報に基づいたマッチング画像としてマッチングルーム画像を生成する。生成したマッチングルーム画像は、サーバ通信部12を経由して各ユーザ端末に送信される。
ここで、各ユーザ端末では、ウェブブラウザのAPIを用いてマッチングルーム画像を表示する。マッチング処理部15がマッチング情報をダイレクトにサーバ通信部12を経由して各ユーザ端末に出力した場合、端末側でAPIを用いてマッチングルーム画像を生成するようにしてもよい。この場合は、マッチングルーム画像そのものをネットワーク30上に送信せず、パラメータ情報を中心にデータ通信を行うこととなり、ネットワークの帯域が狭い環境において好適である。
サーバ通信部12は、各ユーザ端末からの信号を受信し、所定の復調処理を実施して、ユーザ情報管理部13、ゲーム管理部14、マッチング処理部15、画像生成部16に復調された信号を送る。また、ユーザ情報管理部13、ゲーム管理部14、マッチング処理部15、画像生成部16から送られた信号に対して所定の変調処理を実施して、各ユーザ端末に送信する。なお、サーバ通信部12における変復調処理は、従来用いられている変復調技術が用いられてよく、このような態様であったとしても、本発明を適用することができることは当業者に理解されるところである。
つぎに、図5を用いて、マッチング処理部15について説明する。図5は、図2のマッチング処理部15の構成例を示す図である。マッチング処理部15は、受付部210と、マッチング振分部211、マッチング情報生成部212とを含む。
受付部210は、通信回線およびサーバ通信部12を介して、複数のユーザが使用するユーザ端末のそれぞれから、1以上のユーザが参加可能なネットワークゲームに係るチームバトルへの参加要求を受け付ける。要求には、どのクエストに対するチームバトルへの参加要求であるか、ユーザは誰であるか、どの端末からの要求であるか、等のパラメータを抽出し、サーバメモリ17に格納するとともに、当該要求をマッチング振分部211に出力する。
さらに、受付部210は、 参加要求を受け付けたユーザ端末ごとにコメント情報を受け付け、また、ネットワークゲームを進行させるためにエネミーを探索する探索要求を受け付ける。詳細は後述する。
ここで、図6および図7を用いて簡単な説明を行う。図6は、図1のユーザ端末の第1の画面表示例610を示す図である。図7は、図1のユーザ端末の第2の画面表示例620を示す図である。なお、理解を容易とするためにユーザ端末の画面表示を用いているが、これらの画面表示は、サーバ装置10のゲーム管理部14、マッチング処理部15の指示のもとで画像生成部16により生成されて、ユーザ端末の画面に表示させたものである。端末の構成や動作については後述するが、画面がタッチパネルによる入力操作を想定して以下の実施の形態を説明するが、マウス操作等による操作であっても構わないものとする。
第1の画面表示例610には、ソーシャルゲームの基本画面である、ユーザ固有のマイページ画面301と、ゲームを終了する際に用いる戻るボタン302と、各種メニューボタン303と、他のユーザのアバター304と、アバター304に対応するコメント欄305と、バトルを開始するトリガーとなるハントボタン306が表示されている。また、第2の画面表示例620には、第1の画面表示例610の画面に重畳されるように、クエスト選択画面307、アバター308、クエスト選択ボタン309が表示される。
第1の画面表示例610が表示されているときにユーザがハントボタン306へ入力操作を行うと、図7に示す第2の画面表示例620に画面が遷移して、ハントモードとなり、クエスト選択画面307が現れる。ここで、ハントとは、バトルゲーム開始するためのトリガーとなっている。
ハントモードになると、クエスト選択画面307には、ハントボタン306を入力操作したユーザの情報として、アバター308、ユーザ名、ランク、次のランクまでのポイント、残りLP値(Life Point)、LP値ゲージ等が表示される。また、クエスト選択ボタン309が複数現れ、ユーザはそのうちの一つを選択する。
なお、クエストは、それぞれ参加人数上限、難易度、獲得報酬等が異なっている。ユーザは、自身のステータスやデッキの強さ等を考慮して、適当なクエストを選択するように入力操作を行う。なお、クエスト選択ボタン309には、難易度、獲得報酬等が表示されるようになっている。クエストでは、複数のユーザからなるチームを編成し、エネミーキャラクタと戦うチームバトルが行われる。
クエスト選択ボタン309が入力操作されたことをトリガーとして、ユーザ端末は、サーバ装置10と通信を行い、受付部210に参加要求が伝えられることとなる。
図5に戻る。マッチング振分部211は、クエスト選択ボタン309に入力操作がされたことに応じて、参加要求を行った各ユーザをチームに割り振る処理を行い、その情報をサーバメモリ17にアップロードするとともに、マッチング情報生成部212にも出力する。このような操作は各クエストの参加人数上限に達するまで継続されることとなる。
マッチング情報生成部212は、マッチング振分部211からの出力と、サーバメモリ17の情報に基づき、各ユーザ端末に送信するマッチングルーム画像を生成するためのマッチング情報をユーザ端末毎にそれぞれ生成する。具体的には、以下のような例が挙げられる。
・マッチング情報
ユーザ1の情報
ユーザ3の情報
ユーザ2の情報
上記においては、同じクエストに参加要求を行ったユーザの情報を上から参加要求順に記載している。ここで、ユーザ3が2番目に参加要求を行った場合、ユーザ3よりも先にユーザ1の情報がマッチング情報に含まれることとなる。そして、マッチング情報に基づくマッチングルーム画像を生成すると、先にユーザ1のアバターが含まれてしまい、ユーザ3は、後からチームにゲスト参加したという印象を拭えない。そこで、本実施の形態では、上記の順にユーザが参加要求を行った場合であっても、ユーザ3の端末へ最初に送信するマッチングルーム画面を生成するためのマッチング情報を以下のように生成する。
マッチング情報は、クエストに参加するユーザの情報、参加順位を示す情報、過去のクエスト実績などが含まれてもよい。ユーザの情報には、ユーザIDやユーザ氏名、あるいは、過去にマッチングされたユーザのIDなどが含まれてもよい。クエスト実績には、累積ポイント、勝利回数、参加回数、レベル情報、カード情報などが含まれてもよい。
・マッチング情報(最初)
ユーザ3の情報
つまり、各ユーザの端末に最初に送信するマッチング情報には必ず自身のユーザの情報のみが含まれ、他のユーザの情報は除外するようにしている。
また、ユーザ3のユーザ端末へ2番目に送信するマッチングルーム画面を生成するためのマッチング情報は、例えば、以下の通りとなる。
・マッチング情報(2番目)
ユーザ3の情報
ユーザ1の情報
また、ユーザ3の端末へ3番目に送信するマッチングルーム画面を生成するためのマッチング情報は、例えば、以下の通りとなる。
・マッチング情報(3番目)
ユーザ3の情報
ユーザ1の情報
ユーザ2の情報
上記は、ユーザ3に送信するためのマッチング情報であるが、ユーザ2に送信するためのマッチング情報は、以下のとおりとなる。
・マッチング情報
ユーザ2の情報
ユーザ1の情報
ユーザ3の情報
すなわち、マッチング情報におけるユーザ情報の順序は、通知先の端末のユーザ情報を第1位とし、第2位以降を通知先以外の端末のうち参加順序の早い順となる。なお、マッチング情報におけるユーザ情報の順序は、通知先の端末のユーザ情報を第1位とすれば、第2位以降はランダムにしても良い。
以上のように、本実施の形態においては、端末の操作を行うユーザの情報を優先的にマッチング情報に含め、次のマッチング情報を生成する際に、参加要求順にかかわらず一人ずつユーザの情報を追加していく構成としている。
しかしながらこれにかぎらず、先に送信したマッチング情報との差分のユーザ情報のみが含まれるようにしてもよい。また、2番目以降のマッチング情報は、後述する探索要求を受付部210が受け付けたことを契機として生成されてもよい。また、前述した1番目〜3番目のマッチング情報を生成するたびに送信するのではなくて、参加ユーザの数が定員に達した後に生成されたマッチング情報のみを生成してもよい。このような態様であっても、通知先のユーザ端末がもっとも早く参加要求をしたかのごとく示すことができる。これにより、ゲームに参加するそれぞれのユーザに対して、自らがゲーム参加表明の一番手であると認識させることができ、もって、そのチームに対して主体的に積極性を持って貢献することを促せるためゲームが白熱しやすくなる。
上記のようなユーザ端末毎にマッチング情報の生成を行うことにより、各ユーザは自身が最初にマッチングルームに入ったように感じ、主体性が芽生え、ゲームを盛り上げようとすることとなり、全体として白熱したゲームを楽しむことが可能となる。
また、他のユーザの情報が一度に追加されず、一人ずつ徐々に追加されることにより、ゲームへの期待感が徐々に高まり、ユーザは高揚感を感じゲームの興趣性を向上させることができる。
ここで、マッチング情報に含める第2位以降のユーザの情報を追加する際の優先順位について工夫を行ってもよい。以下、簡単に説明する。サーバ装置10のサーバメモリ17には、各ユーザ同士の相関を図ることができる過去の履歴情報を有している。例えば、一緒にチームを組んだ回数、直近でチームを組んだ日時からのカウント時間の短さ、SNS上のつながり度合、キャラクタ族種、属性、レベル等の相関等に基づき、親和度の高低を判定し、親和度の高いユーザを優先的にマッチング情報に追加するようにしている。このような工夫を行う場合、まず、あるクエストに対して参加要求を行ったユーザのユーザ情報をプールし、その中から、上記の各ユーザ同士の相関を図ることができる過去の履歴情報に基づき、ユーザ同士のマッチングを行う。
親和度の高いユーザの情報が優先的に追加されることにより、端末を操作するユーザにとっては、親しいユーザが急いで集まってきてくれたように感じ、高揚感を高めゲームの興趣性を向上させることができる。また、親和度の高いユーザ同士が同じチームとしてマッチングされるため、ユーザ間で交流が行われる可能性が高まり、ユーザ間の交流をより活性化させることができる。
ここで、図8、図9を用いて、マッチング情報生成部212によって生成されたマッチング情報がユーザ端末に通知された際の画面について説明する。図8は、図1のユーザ端末の第3の画面表示例630を示す図である。図9は、図1のユーザ端末の第4の画面表示例640を示す図である。第3の画面表示例630、第4の画面表示例640は、参戦アナウンス欄315と、タイマー欄316と、ユーザ情報の表示欄401と、マッチングルーム画像402が表示される。
マッチングルーム画像402の表示欄401には、チームバトルへ参加要求を行い同じチームに割り振られたユーザの情報として、アバター、および、コメントと共に表示される。ここで、マッチングルーム画像402には、直近で追加されたユーザの情報に基づき、ユーザ名が表示される参戦アナウンス欄315と、チームバトルへの参加締切残り時間を表示するタイマー欄316とが表示されている。
図9の第4の画面表示例640に示すように、表示欄401にユーザの情報が順次表示され、アバタ―画像やコメントが増えていく。つまり、タイマー欄316に示された「残り時間3分」における第3の画面表示例630では、自身のユーザの情報のみが表示されているだけであったのが、「残り時間2分」における第4の画面表示例640では、他のユーザの情報が追加されている。これは、ユーザの参加要求順がいかなる場合であれ、このような順での表示となる。なお、マッチングルーム画面402を閲覧するユーザ自身のユーザ情報は不要である場合も多く、その場合は、積極的に自身のユーザの情報をマッチングルーム画面402に表示する必要はない。本実施の形態はそれをも内包するものであることは言うまでもない。
つぎに、ユーザ端末において、図7に示した第2の画面表示例620におけるクエストボタン309が入力操作された後の処理について、図10を用いて説明する。図10は、図1のユーザ端末の第5の画面表示例650を示す図である。第5の画面表示例650には、メニュー画像310と、メンバ選択ボタン311と、入力欄312と、再選択ボタン313が表示される。
図7に示した第2の画面表示例620のクエストボタン309が入力操作された後、第5の画面表示例650に画面表示が遷移して、メンバ選択及びコメント入力メニュー画像310が表示され、メニュー画像310にはチームを編成するメンバの限定をセレクトするメンバ選択ボタン311が表示される。
第5の画面表示例650においては、メンバ選択ボタン311としては2つ表示され、SNSにおける「友達に限定する」、あるいは、「誰でもOK」のいずれかのモードを選択できる。また、あいさつ文を入力することができる入力欄312があり、挨拶コメントを入力することで他のユーザと親交を深めることができる。なお、クエストを選びなおす処理を行うための再選択ボタン313も表示される。再選択ボタン313が入力操作された場合には、図7に示すクエスト選択画面307へ戻る操作が行われる。
ここで、メンバ選択ボタン311で「誰でもOK」モードが選択された場合、所定の時間内に同じクエスト選択ボタン309を選択したユーザ同士が同じチームに割り振られることとなる。ただし、チームバトルへの参加要求者がそのクエストのチーム上限定員に達すると、チーム割り振りは終了し、チームバトルゲームが進行する。また、チームバトルへの参加上限に到達しないまま、参加締切時間となった場合には、一般のユーザではなく、いわゆるNPC(Non Player Character)を補充してゲームを進めるようにしてもよい。欠員が出た状態では、チームの戦闘力が低下しゲームの進行に支障をきたしたり、ユーザの高揚感が阻害されてしまう恐れがあるからである。
つぎに、ユーザ端末において、メンバ選択ボタン311、入力欄312へのコメントの入力操作がなされると、当該チームバトルに参加しているそれぞれのユーザ端末において図8の第3の画面表示例630、図9の第4の画面表示例640に示すようなマッチングルーム画像402、あるいは、後述する図11のコメントスクロール欄317において、コメントを入力したユーザ端末に対応するアバタ―画像に対応する態様で当該コメントが表示されることとなる。
マッチングルーム画像402は、探索ボタン314等のチームバトル用のボタンが複数表示され、入力操作が可能となっている。ユーザは、マッチングルームにおいて、探索ボタン314を入力操作することにより、最終的にはエネミーを発見し、編成されたチームによってバトルゲームに突入することとなる。
なお、図8、図9に示す第2の画像表示例620、第3の画像表示例630は、図11に示す第3の画像表示例410とは、異なる態様のものである。いずれもマッチングルーム画像402を表しているが、第2の画像表示例620、第3の画像表示例630では、チームバトルへ参加要求を行ったユーザの情報が、例えばアバターやコメントが組合わされて整列するように配置されている。
図11は、ユーザ端末の第6の画面表示例660を示す図である。第6の画面表示例660には、コメントスクロール欄317、318、アバター403、チームメンバ表示欄404が表示される。
具体的には、チームバトルへ参加要求を行ったユーザの情報が、例えばアバター403としてチームメンバ表示欄404に順次表示され、コメントがコメントスクロール欄317、318に表示され自動的にスクロールするようにされている。コメントが表示される際には、当該コメントを入力したユーザ端末に対応するアバターが点滅するなどの処理がなされてもよい。以上により、マッチングルーム画像402にオーバレイ表示したコメントが流れていくこととなり演出効果が高まる。
チームバトルが開始される前の待ち時間の間、ユーザはマッチングルームにおいて、コメントを用いたチャットを行いながら他のユーザと会話を楽しむことで各ユーザに待ち時間で退屈させないような態様としてもよい。
ここで、具体的に、マッチングルームで待機中のユーザが行うアクションについて説明する。ユーザは、探索ボタン314を入力操作することにより、例えばフィールドを探索するミッションゲームを行うことができる。チームバトルを開始するまでの時間を使った余興を行い、ユーザを退屈させないためである。このようなミッションゲームにおいて、ユーザは、経験値、ゲーム内通貨、カードやアイテム等の各種ゲーム媒体を得ることができる。ユーザは、探索ボタン314を入力操作する毎に他のユーザが徐々にチームに加わってくることとなる。
なお、このような余興は、ミッションゲームには限定されず、クイズゲームやシューティングゲームであってもよい。また、ミッションゲーム等を行っている際に、「分析中・・・」、「分析結果:敵のデータは・・・弱点は・・・」のようにこれから戦う敵の情報を事前に教えるような表示を出してもよい。このような処理を行うことで、マッチングルーム画面での待ち時間がより有意義なものとなり、ユーザのゲームへの興味関心を高めることができる。
つぎに、チームバトルモードに突入した場合について、図12を用いて説明する。図12は、図1のユーザ端末の第7の画面表示例670を示す図である。第7の画面表示例670は、エネミー501、バトル画像502、攻撃ボタン503が表示された例である。
チームバトルモードでは、バトル画像502の欄にエネミー501が表示される。第7の画面表示例670は、マッチングルーム画面とは異なり、探索ボタン314が存在せず、代わりにエネミーに対して攻撃を開始するための攻撃ボタン503が表示されている。各ユーザは攻撃ボタン503を入力操作することによりエネミーへ攻撃を行う等、バトルを進めて行くこととなる。
つぎに、ユーザ端末側の構成について、図13を用いて説明する。図13は、図1のモバイル端末50あるいはPC端末70における構成例を示す図である。ここでは、説明の都合上、モバイル端末50の構成として説明するが、PC端末70においても同様の構成となる。
モバイル端末50は、端末通信部52と、端末制御部54と、ユーザインタフェース56と、端末メモリ58とを備える。端末通信部52は、サーバ装置10からダウンロードしたアプリや、サーバ装置10から送信される各種情報を受信する。
端末制御部54は、ユーザインタフェース56を介してユーザからの指示を受け付けて、端末メモリ58にアクセスしながら、アプリのインストール制御や、ソーシャルゲームのAPI制御などを行う。
また、ユーザインタフェース56は、ユーザへのメッセージ、ソーシャルゲームマッチングルーム画面等の各種画面を表示するための画面インタフェースと、キーボードやタッチパネルなどのユーザからの入力を受け付ける入力インタフェースと、カメラなどの画像撮像手段を含む。
ユーザインタフェース56は、ユーザからのクエストの選択すなわちチームバトル参加要求、あるいは、各種のコメント入力、アクションボタン操作等を受け付けて、端末制御部54に伝える。
端末メモリ58は、アプリ提供プラットフォームからアプリゲームをダウンロードした際に、そのアプリプログラムを格納することに用いられる。また、ブラウザゲームにおいても、キャッシュメモリや、画像データの一時保管等に用いられる。
以下、ユーザAがチームバトルへ参加要求を行った場合の動作の一例として、ブラウザゲームを想定したユーザ端末の総括的な動作を説明する。
ユーザAが、ウェブブラウザを立ち上げ、ソーシャルゲームサイトを選択すると端末制御部54は、端末通信部52を用いてサーバ装置10と通信を行いウェブブラウザ上で動作する形でソーシャルゲームのデータを受信しこれを実行する。
ユーザインタフェース56には、ソーシャルゲームへのログイン手続きを行う案内が表示される場合があるが、ここでは簡略のため説明を省略し、ソーシャルゲームが開始されたものとして説明する。
ユーザインタフェース56には、図6に示す、第1の画面表示例610が表示され、ユーザAが、ハントボタン306へ入力操作を行う。端末制御部54は、端末通信部52を用いてサーバ装置10と通信を行い図7に示すクエスト選択画面307をダウンロードし、端末メモリ58に格納し、クエスト選択画面307をユーザインタフェース56に表示する。
つぎに、ユーザAが、クエスト選択ボタン309へ入力操作を行う。端末制御部54は、端末通信部52を用いてサーバ装置10と通信を行いクエスト選択ボタン309が入力されたこと、すなわちチームバトルへの参加要求をサーバ装置10に送信するとともに、サーバ装置10から図10に示すメニュー画面310をダウンロードし、端末メモリ58に格納し、メニュー画面310をユーザインタフェース56に表示する。
つぎに、ユーザAが、コメント入力欄312にコメント入力操作を行い、メンバ選択ボタン311へ入力操作を行う。端末制御部54は、端末通信部52を用いてサーバ装置10と通信を行い、入力されたコメント情報とメンバ選択情報をサーバ装置10に送信するとともに、サーバ装置10から図8に示すマッチングルーム画像402をダウンロードし、端末メモリ58に格納し、マッチングルーム画像402をユーザインタフェース56に表示する。
ここで、サーバ装置10では、マッチングルーム画像402を生成するに際して、ユーザAの端末からチームバトルへの参加要請を受け付けた段階で、同じクエストを選択した他のユーザが存在した場合であっても他のユーザの情報はマッチングルーム画像402には含めないようにしてユーザ端末に送信している。
つぎに、ユーザAが、マッチングルーム画像402が表示され、探索ボタン314へ入力操作を行う。端末制御部54は、端末通信部52を用いてサーバ装置10と通信を行い、探索ボタン314に対応するミッションゲームに応じた画像等をサーバ装置10からダウンロードし、端末メモリ58に格納し、ミッションゲームに応じた画像をユーザインタフェース56に表示する。
つぎに、ユーザAが、マッチングルーム画像402が表示された状態で、サーバ装置10に対して同じクエストへの参加要求をした他のユーザの情報が存在する場合に、サーバ装置10では、マッチングルーム画像402を生成するに際して、図9に示すように、ユーザAとともに他のユーザの情報をマッチングルーム画像402に含めてユーザ端末に送信してもよい。
つぎに、端末制御部54は、端末通信部52を用いてサーバ装置10と通信を行い、サーバ装置10から図9に示すマッチングルーム画像402をダウンロードし、端末メモリ58に格納し、マッチングルーム画像402をユーザインタフェース56に表示する。
つぎに、サーバ装置10は、チームバトルへの参加要求の受付時間が経過すると、ユーザ端末にエネミー501やチームバトルに参加するユーザの情報を含めたバトル画像502を送信する。
つぎに、端末制御部54は、端末通信部52を用いてサーバ装置10と通信を行い、サーバ装置10から図12に示すエネミー501がダウンロードされ、端末メモリ58に格納し、エネミー501をユーザインタフェース56に表示する。
つぎに、ユーザAが、攻撃ボタン503へ入力操作を行うと、サーバ装置10に攻撃をする旨の情報を通信し、バトル処理がサーバ装置10内で進行する。以後、バトルが終了するまでユーザAの操作に基づき動作が繰り返され、サーバ装置10は、エネミー501の画像やエネミーの体力消耗を含めたバトル画像502をユーザ端末に送信する。
図14は、図2のマッチング処理部15の処理手順例を示すフローチャートである。このフローチャートは、ユーザ端末から本ソーシャルゲームを開始する旨の操作が行われたことを契機として開始されてもよい。
まず、マッチング処理部15は、サーバ通信部12を介して、ユーザ端末からユーザAや他のユーザのチームバトルへの参加要求を受け付ける(S10)。参加要求は、先にも述べたとおり、クエスト選択ボタン309の操作によりなされるものである。参加要求があった場合には、サーバメモリ17へ、ユーザの情報や端末の情報とともに記憶される。
ここで、参加要求を受け付けたユーザAにこのクエストにおけるマッチング情報またはマッチングルーム画像を送るのが最初であるかをサーバメモリ17の記録より判断し、最初である場合(S11のYes)には、他のユーザの情報を含めずにマッチング情報を生成する(S12)。一方、最初でない場合(S11のNo)には、チームバトルへの参加要求を行っている他のユーザのうち、例えば一番先に参加要求を行ったユーザの情報を一人分含めてマッチング情報を生成する(S14)。このとき、各ユーザ同士の相関を図ることができる過去の履歴情報を用いて、チームバトルへの参加要求を行っている他のユーザのうち、ユーザAと親和度の高いユーザを抽出し、その中のユーザの情報を一人分含めてマッチング情報を生成してもよい。
つぎに、生成されたマッチング情報をユーザAのユーザ端末に送信する(S13)。ここで、マッチング情報に基づきマッチングルーム画像を生成してユーザ端末に送信することも可能であることは上述で説明したとおりである。
最後に、マッチング処理部15は、マッチング時間が終了したか、チームバトルへの参加人数が上限に達したか等、マッチングを終了すべき状態にあるかを判断し、終了であれば(S15のYes)処理を終え、終了でなければ(S15のNo)、終了条件になるまでフローを繰り返す処理を行う。
図15は、図13の端末制御部54の処理手順例を示すフローチャートである。このフローチャートは、ユーザ端末にゲームアプリケーションプログラムをインストールするアプリゲームに適用した場合において、ユーザ端末から本ソーシャルゲームを開始する旨の操作が行われたことを契機として開始される。
まず、端末制御部54は、ユーザインタフェース56からユーザAのチームバトルへの参加要求の操作を受け付ける端末通信部52を介してサーバ装置10に参加要求情報を送信する(S20)。参加要求は、先にも述べたとおり、クエスト選択ボタン309の操作によりなされるものである。
つぎに、端末制御部54は、端末通信部52を介して、サーバ装置10からその時点で同じクエストに参加要求を行っているすべてのユーザの情報を取得する(S21)。上述では、サーバ装置10にてマッチング情報の加工を行っているが、アプリゲームの場合は端末側でその処理を行うことができるためすべてのユーザの情報を取得しても問題はない。本実施の形態における一つの変形例である。
ここで、端末制御部54は、参加要求を受け付けたユーザAにこのクエストにおけるマッチング情報またはマッチングルーム画像を生成するのが最初であるかを判断し、最初である場合(S22のYes)には、他のユーザの情報を含めずにマッチング情報を生成しこれに基づくマッチングルーム画像を生成する(S23)。一方、最初でない場合(S22のNo)には、チームバトルへの参加要求を行っている他のユーザのうち、例えば一番先に参加要求を行ったユーザの情報を一人分含めてマッチング情報を生成する(S25)。このとき、各ユーザ同士の相関を図ることができる過去の履歴情報を用いて、チームバトルへの参加要求を行っている他のユーザのうち、ユーザAと親和度の高いユーザを抽出し、その中のユーザの情報を一人分含めてマッチング情報を生成しこれに基づくマッチングルーム画像を生成してもよい。なお、親和度を判断するパラメータは端末側で保持しているものを使ってもよいし、サーバ装置10と通信を行い取得するなどいずれの方法を用いてよい。
つぎに、端末制御部54は、生成したマッチングルーム画像をユーザインタフェース56に表示する(S24)。
最後に、端末制御部54は、マッチング時間が終了したか、チームバトルへの参加人数が上限に達したか等、マッチングを終了すべき状態にあるかを判断し、終了であれば(S26のYes)処理を終え、終了でなければ(S27のNo)、終了条件になるまでフローを繰り返す処理を行う。なお、マッチングを終了すべき状態にあるか否かを判断するパラメータの取得は、参加要求情報の取得(S21)において適宜行えばよい。
以上のように、各態様に応じて説明を行ったが、マッチング処理を行うに際して、チームのマッチング状況を示すマッチング情報もしくは端末側で表示されるマッチング画像(マッチングルーム画像)に、それぞれのユーザにとって自身が一番最初にチームに参加したと感じさせることで、ユーザのソーシャルゲームへの主体性を大きく向上させ、各ユーザがこのソーシャルゲームに積極的に参加することとなり、ゲーム全体が白熱して面白くなるといった効果を得ることができる。
以上、本発明を実施例をもとに説明した。本発明は上述した実施例並びに各実施例の内容に限定されるものではなく、本発明の要旨の範囲内において種々に変形して実施をすることが可能である。上記実施例は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。