JP2014097129A - ゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラム - Google Patents

Abstract

【課題】ユーザにとって関心の持てる相手に対して、手間を掛けることなく円滑に仲間申請することを可能とする。
【解決手段】ゲーム管理装置は、ユーザ同士が仲間関係を構築することができるゲームを管理するものであって、ユーザのゲーム画面に登場した他のユーザに関する情報の履歴をデータベースサーバ２に記憶する履歴記憶制御手段５１と、歴記憶制御手段５１によって記憶された前記履歴に基づいて、ユーザのゲーム画面に登場した、当該ユーザと仲間関係にない同一の他のユーザに関する情報が所定回数以上になったと判断した場合に、当該他のユーザを仲間候補として前記ユーザに薦める推薦手段５２とを備え、ゲーム管理装置側からユーザに対して、仲間関係構築のマッチングを積極的に仕掛ける。
【選択図】図１１

Description

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

従来から、インターネット上に設置されたゲームサーバに、ユーザの端末装置（パーソナルコンピュータ、携帯電話端末等）を接続することによって、ユーザがゲームサーバから提供される各種ゲームサービスを受けることができるゲームシステムがある。

また、インターネットを介して共通のゲームをプレイするユーザ同士が、仲間関係を構築することができるゲームシステムも提案されている（特許文献１参照）。

そして近年、人と人とのつながりを促進・サポートするコミュニティ型のサービスであるソーシャルネットワーキングサービス（ＳＮＳ）のシステムに、前記ゲームシステムが組み込まれ、ＳＮＳのサービスの一つとして提供される、いわゆるソーシャルゲームが普及している。このようなソーシャルゲームにおいては、各ユーザがゲームサービスを利用している他のユーザと仲間になり、仲間のユーザとコミュニケーションをとったり、協力して対戦したりすることで、ユーザ同士が交流を行うことができるようになっている。そして、各ユーザは、複数の他のユーザと仲間になって、これらの仲間と交流を持ちながらゲームを楽しむことができるようになっている。

２人のユーザが仲間関係を構築する場合、一方のユーザが他方のユーザに対して仲間申請を行い、当該仲間申請を受けたユーザがそれを承認するという、両ユーザ間においてなされる仲間申請とその承認の操作が挙げられる。ユーザが仲間を作るための操作を行えば、ゲームサーバが複数の他のユーザを仲間候補としてランダムに選択し、ユーザの端末装置の画面に仲間候補リストを表示させる。ユーザは、仲間候補リストの中から仲間になりたい他のユーザを選択して仲間申請を行う。

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

しかしながら、仲間候補がランダムに抽出された仲間候補リストの中に、ユーザにとって関心のある相手が含まれていないこともあり、ユーザは、何度も仲間候補リストを更新しながら、手間を掛けて、仲間になりたい相手を探すことも多かった。

本発明は、上記の問題に鑑みてなされたものであり、その目的は、ユーザにとって関心の持てる相手に対して、手間を掛けることなく円滑に仲間申請することを可能にするゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラムを提供することである。

１）本発明の一局面によるゲーム管理装置（1,2,101,102,301,302）は、ユーザ同士が仲間関係を構築することができるゲームを管理するものであって、ユーザのゲーム画面に登場した他のユーザに関する情報の履歴を記憶装置に記憶する履歴記憶制御手段（51）と、前記履歴記憶制御手段（51）によって記憶された前記履歴に基づいて、ユーザのゲーム画面に登場した、当該ユーザと仲間関係にない同一の他のユーザに関する情報が所定回数以上になったと判断した場合に、当該他のユーザを仲間候補として前記ユーザに薦める推薦手段（52）と、を備えている。

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

また、本ゲーム管理装置は、ユーザ同士が仲間関係を構築することができるゲーム、例えばプレイヤ同士が仲間になって交流を楽しむことができるソーシャルゲーム、オンラインゲーム等のゲームの管理を行う。ここで、仲間関係とは、ゲーム内で構築されるプレイヤ同士の仮想的な関係の総称であり、知人、友人、友達、クラスメイト、相棒、親類、家族、兄弟、姉妹、会社や組織の同僚などの様々なゲーム内の関係を含む。

本ゲーム管理装置は、ユーザＡの画面に同一の他のユーザＢに関する情報が所定回数以上（例えば３回以上）登場した場合に、ユーザＡに対して他のユーザＢを仲間候補として薦めることにより、仲間になる切っ掛けを与える。

これを実現するゲーム管理装置は、ユーザのゲーム画面に登場した他のユーザに関する情報の履歴を記憶手段に記憶する履歴記憶制御手段を備える。ここで、「他のユーザに関する情報」の例としては、他のユーザの分身的キャラクタ（いわゆるプレイヤキャラクタ）、他のユーザが所有するキャラクタ（例えば野球ゲームでは、他のユーザのチームに所属する選手キャラクタ）、他のユーザのアバターや写真、他のユーザの名前（ニックネームであってもよい）などを挙げることができる。また、ビデオチャット等においては、ユーザの画面に他のユーザ自身の画像が登場する場合もある。

なお、以降の説明において、便宜上、「他のユーザがゲーム画面に登場する」旨の表記をすることもあるが、これは、他のユーザの分身的キャラクタ、所有キャラクタ、アバター、写真、チャット画像などを含む他のユーザに関する情報が、ゲーム画面に登場することを表すものとする。

ユーザのゲーム画面に他のユーザに関する情報が登場する例としては、対戦ゲームにおいて、対戦ゲーム画面にユーザの対戦相手として他のユーザの分身的キャラクタ（または他のユーザの所有キャラクタ）が登場する場合が挙げられる。この場合、履歴記憶制御手段は、対戦相手のユーザＩＤおよび画面に登場した時間情報等を履歴として記憶装置に記憶する記憶制御を行う。なお、対戦ゲーム中、例えば野球ゲームであれば野球の試合中に、他のユーザのキャラクタが、複数回、画面に登場することもあるが、同一の試合中であれば何度登場したとしても、登場回数としては１回としてカウントすることができる。

また、ユーザが対戦を行う場合、先ず、対戦相手候補リスト画面に複数の対戦相手候補の情報が表示され、その中からユーザが任意の対戦相手を選択できる場合、次のようにすることができる。すなわち、ユーザが実際に対戦相手として選択した他のユーザだけではなく、対戦相手候補として画面に表示されただけの他のユーザも、ユーザのゲーム画面に登場した他のユーザとして、履歴記憶制御手段がその履歴を記憶装置に記憶してもよい。

その他の例としては、ユーザが対戦を行う際に、仲間に関係なく、誰にでも助っ人として対戦協力を要請できる場合、履歴記憶制御手段は、助っ人としてユーザのゲーム画面に登場した他のユーザに関する情報の履歴を、記憶手段に記憶する。この場合も、ユーザが実際に助っ人として依頼した他のユーザだけではなく、助っ人候補として画面に表示された他のユーザも、ユーザのゲーム画面に登場した他のユーザとして、履歴記憶制御手段がその履歴を記憶装置に記憶してもよい。

その他の例としては、履歴記憶制御手段は、レイドボス戦のゲーム画面に登場する、ユーザと協力して戦う他のユーザに関する情報の履歴を、記憶手段に記憶する。なお、レイドボス戦とは、後記するように、複数のユーザがパーティ（グループ）を組み、互いに協力しながらボスに立ち向かう協力プレイをいう。また、履歴記憶制御手段は、ゲーム内の仮想的なコミュニティルームにユーザが入室した際に、当該ルーム内で一緒になった他のユーザに関する情報の履歴を、記憶手段に記憶する。なお、これらはほんの一例であって、ユーザのゲーム画面に他のユーザが登場する機会は様々である。

そして、推薦手段は、履歴記憶制御手段によって記憶された前記履歴に基づいて、ユーザＡのゲーム画面に登場した、当該ユーザＡと仲間関係にない同一の他のユーザＢに関する情報が所定回数以上（例えば３回以上）になったと判断した場合に、当該他のユーザＢを仲間候補として前記ユーザＡに薦める。仲間候補として薦める一例としては、架空のキャラクタが、ユーザＡに対して、他のユーザＢと仲間になってはどうかと話かけるような演出を行うことであり、例えばユーザＡがその演出に応えると、他のユーザＢに簡単に仲間申請できるようにする。

なお、ユーザＡのゲーム画面に、偶然、他のユーザＢが複数回登場した場合にも、あるいは後述する２）の構成のように、ゲーム管理装置が所定基準を満たす他のユーザＢのゲーム画面への登場頻度を高めた結果として他のユーザＢが複数回登場した場合の何れでも、他のユーザＢを仲間候補としてユーザＡに薦める。

ユーザＡにとって、自分のゲーム画面に何度も登場した他のユーザＢについては、関心を引く存在になっていると考えられる。そこで、従来のように、ユーザＡが自主的に仲間を作るための操作を行ったときにだけ、ランダムに仲間候補リストを表示するだけではなく、本構成では、ゲーム管理装置側からユーザＡに対して、仲間関係構築のマッチングを積極的に仕掛け、他のユーザＢを仲間候補としてユーザＡに薦めるのである。

また、従来、ランダムに抽出された仲間候補リストの中から仲間になりたい相手を探す場合、ユーザにとって関心のある相手が仲間候補リストに含まれておらず、何度も仲間候補リストを更新しながら、ユーザが手間を掛けて、仲間になりたい相手を探すことも多かった。これに対して、本構成では、ユーザＡの画面に登場した他のユーザＢの回数が所定回数以上になり、ユーザＡが他のユーザＢに関心を持ったころに、タイミングよくゲーム管理装置が他のユーザＢを仲間候補としてユーザＡに薦めるので、ユーザＡはゲームをしながら手間を掛けることなく円滑に仲間をつくることができるようになる。

２）上記の構成において、第１のユーザと仲間関係にない他のユーザの中から、所定の選択基準に基づいて、仲間候補となり得る第２のユーザを選択する選択手段（53）と、前記選択手段（53）によって選択された第２のユーザに関する情報を、第１のユーザのゲームプレイの相手または相手候補として、第１のユーザのゲーム中の画面に登場させる頻度を、第２のユーザ以外の他のユーザに関する情報よりも高くする相手管理手段（54）と、をさらに備えていることが望ましい。

この構成によれば、第１のユーザＡの仲間ではなく、且つ所定の選択基準を満たす第２のユーザＢ（Ｃ、Ｄ…）が選択され、第１のユーザＡのゲーム画面に登場する頻度がゲーム管理装置によって高められる。この詳細を以下に説明する。

先ず、選択手段が、第１のユーザＡと仲間関係にない他のユーザの中から、所定の選択基準に基づいて、仲間候補となり得る第２のユーザＢ（Ｃ、Ｄ…）を選択する。ここで、所定の選択基準の例としては、ゲームへのアクセス頻度、仲間数、ゲーム開始日時、年齢などが第１のユーザＡと同一またはその違いが所定範囲内とすることができる。また、所定の選択基準の他の例としては、対戦ゲームにおいて、対戦頻度、勝率などが第１のユーザＡと同一またはその違いが所定範囲内とすることができる。また、第１のユーザＡの直近の所定試合（例えば２０試合）の対戦相手という選択基準を設けてもよい。さらにまたユーザのゲーム内でのレベルを選択基準とすることも考えられる（例えば、第１のユーザＡのレベルと同一またはその違いが所定範囲内とする）。また、選択基準は、上記のような各基準を単独で、または種々組み合わせて採用することができる。これらは一例であり、ゲームの種類や内容に応じて様々な選択基準を適用できる。選択基準としては、出来るだけ第１のユーザＡが関心を持ちそうな第２のユーザが抽出できるようなものとすることが好ましい。

そして、相手管理手段が、選択手段によって選択された第２のユーザＢ（Ｃ、Ｄ…）に関する情報を、第１のユーザＡのゲームプレイの相手または相手候補として、第１のユーザＡのゲーム中の画面に登場させる頻度を、第１のユーザＡと仲間関係にないその他のユーザよりも高くする。ここで、「ゲームプレイの相手または相手候補」とは、例えば、対戦相手、対戦相手候補、共同プレイ相手（対戦協力をする助っ人、レイドボス戦の協力メンバ等）または共同プレイ相手候補などを挙げることができる。

以上のように、本構成では、ゲーム管理装置が、所定の選択基準を満たす第２のユーザＢ（Ｃ、Ｄ…）の、第１のユーザＡのゲーム画面への登場頻度を高くすることで、ゲームを行う中で自然と、第１のユーザＡに第２のユーザＢ（Ｃ、Ｄ…）に対する関心を持たせ、仲間づくりへの導線とすることができる。特に、第１のユーザＡが関心を持ちそうな第２のユーザを選択できるような任意の選択基準（例えば、ゲーム開始日時、年齢、出身地等が、第１のユーザＡと同一またはその違いが所定範囲内とする第１のユーザＡとの共通性に着目した基準）を採用すれば、当該第２のユーザが仲間候補として第１のユーザＡに薦められた場合に、偶然に所定回数登場した他のユーザよりも、第１のユーザＡが関心を持つ（よって仲間になろうとする）可能性を高めることができる。

また、ユーザＡのゲーム画面に、他のユーザＢが所定回数（例えば３回）登場することを、偶然（ランダム）に任せていると、特にゲームに登録しているユーザ数が数万人以上と多い場合は、所定回数の登場までに長時間がかかる（または所定回数登場する確率が極めて低くなる）こともあり得る。これに対し、本構成では、所定の選択基準を満たす第２のユーザＢ（Ｃ、Ｄ…）の第１のユーザＡのゲーム画面への登場頻度を意図的に高くしているので、比較的短い期間内に第２のユーザＢ（Ｃ、Ｄ…）が登場し易くなり、第１のユーザＡが第２のユーザＢ（Ｃ、Ｄ…）に関心を持ち易い状況を作り出すことができる。

３）上記の２）の構成において、前記履歴記憶制御手段（51）は、ユーザのゲーム画面に登場した他のユーザに関する情報のうち、ユーザとゲーム内で接点を持った他のユーザに関する情報の履歴を記憶装置に記憶し、前記選択手段（53）は、第１のユーザと仲間関係にないユーザであって、過去に第１のユーザとゲーム内で接点を持ったことのある他のユーザを、接点を持ったことのない他のユーザよりも優先的に前記第２のユーザとして選択することが望ましい。

例えば、単に対戦相手候補や助っ人候補として第１のユーザＡのゲーム画面に登場しただけの他のユーザよりも、候補リストの中からユーザによって選択されて実際に第１のユーザＡと直接的にゲーム内で接点を持った（例えば、対戦した、助っ人を依頼した、チャットをした）他のユーザの方が、第１のユーザＡにとっては印象深く関心を引く存在となっている。そこで、本構成では、第１のユーザＡとゲーム内で接点を持った他のユーザを、優先的に、仲間候補となり得る第２のユーザとして選択する。

これを実現するゲーム管理装置は、履歴記憶制御手段が、ユーザのゲーム画面に登場した他のユーザに関する情報のうち、ユーザとゲーム内で接点（交流）を持った他のユーザに関する情報の履歴を記憶手段に記憶する。ここで、「ユーザとゲーム内で接点を持った他のユーザ」の例としては、対戦相手、共同プレイ相手（対戦プレイの助っ人、レイドボス戦の協力メンバ等）、ゲーム内コミュニティルームで会話（チャット）した相手などを挙げることができる。これらは一例であり、ユーザと他のユーザとがゲーム内で直接的に接点を持つ態様は、ゲームの種類や内容に応じて様々である。

そして、選択手段は、第１のユーザＡとゲーム内で接点を持った他のユーザに関する情報の履歴に基づいて、第１のユーザＡと仲間関係にない他のユーザであって、過去に第１のユーザＡとゲーム内で接点を持ったことのある他のユーザを、接点を持ったことのない他のユーザよりも優先的に前記第２のユーザとして選択する。よって、第１のユーザＡと過去にゲーム内で接点を持ったことのある第２のユーザは、第１のユーザＡのゲーム画面に登場する頻度が高まり、仲間候補として第１のユーザＡに薦められ易くなる。

本構成により、ユーザが強い関心を持つと思われる他のユーザ（例えば候補リストの中からユーザによって選択されて実際にユーザと直接的にゲーム内で接点を持った他のユーザ）を優先的に仲間候補として薦めることができ、ユーザが薦められた仲間候補に対して仲間申請する可能性を高めることができる。これにより、仲間構築の促進を図ることができる。

４）上記の３）の構成において、前記推薦手段（52）は、ユーザとゲーム内で所定回数以上接点を持ってユーザのゲーム画面に登場した他のユーザを、当該ユーザに仲間候補として薦めることが望ましい。

この構成によれば、例えば、ユーザＡの対戦相手となる等してゲーム内で所定回数以上（例えば３回以上）の接点を持ってユーザＡの画面に登場した他のユーザＢを、仲間候補としてユーザＡに薦める。すなわち、単に候補リスト画面に登場しただけでは足りず、実際に対戦相手等として直接的な接点を持ってユーザＡの画面に所定回数以上登場することが仲間候補の条件であり、そのような仲間候補がユーザＡに薦められる。

よって、ユーザが強い関心を持つと思われる他のユーザ（例えば候補リストの中からユーザによって選択されて実際にユーザと直接的にゲーム内で接点を持った他のユーザ）のみを仲間候補として薦めることができ、ユーザが薦められた仲間候補に対して仲間申請する可能性を高めることができる。これにより、仲間構築の促進を図ることができる。

５）上記の１）ないし４）の何れかの構成において、前記推薦手段（52）は、ユーザに仲間候補として薦めた他のユーザに対して、当該ユーザを仲間候補として薦めることが望ましい。

この構成によれば、ゲーム管理装置は、ユーザＡに他のユーザＢを仲間候補として薦めた場合、当該他のユーザＢにも並行してユーザＡを仲間候補として薦める。すなわち、本構成では、ゲーム管理装置側からユーザＡおよびユーザＢの双方に対して、仲間関係構築のマッチングを積極的に仕掛ける。これにより、例えばユーザＢの方から先にユーザＡに対して仲間申請が届くこともあるが、その場合、ユーザＡにとって、自分のゲーム画面に何度も登場した他のユーザＢについては、関心を引く存在になっていると考えられるので、その仲間申請を承認する可能性は通常よりも高い。本構成により、仲間関係をさらに構築され易くすることができる。

６）本発明の他の一局面によるゲームシステムは、サーバ（1,2,101,102）と、当該サーバ（1,2,101,102）との間で通信を行う端末装置（3,301,302）と、を含むゲームシステムであって、ユーザのゲーム画面に登場した他のユーザに関する情報の履歴を記憶装置に記憶する履歴記憶制御手段（51）、前記履歴記憶制御手段（51）によって記憶された前記履歴に基づいて、ユーザのゲーム画面に登場した、当該ユーザと仲間関係にない同一の他のユーザに関する情報が所定回数以上になったと判断した場合に、当該他のユーザを仲間候補として前記ユーザに薦める推薦手段（52）、を前記サーバ（1,2,101,102）又は前記端末装置（3,301,302）のいずれか一方が備えている。

７）本発明の他の一局面によるゲーム管理方法は、ユーザ同士が仲間関係を構築することができるゲームの管理を行うコンピュータにおけるゲーム管理方法であって、コンピュータが、ユーザのゲーム画面に登場した他のユーザに関する情報の履歴を記憶装置に記憶する履歴記憶制御ステップと、コンピュータが、前記歴記憶制御ステップによって記憶装置にされた前記履歴に基づいて、ユーザのゲーム画面に登場した、当該ユーザと仲間関係にない同一の他のユーザに関する情報が所定回数以上になったと判断した場合に、当該他のユーザを仲間候補として前記ユーザに薦める推薦ステップと、を含んでいる。

８）本発明の更に他の一局面によるプログラムは、コンピュータを、ユーザ同士が仲間関係を構築することができるゲームを管理するゲーム管理装置として動作させるためのプログラムであって、前記コンピュータを、ユーザのゲーム画面に登場した他のユーザに関する情報の履歴を記憶装置に記憶する履歴記憶制御手段（51）、前記履歴記憶制御手段（51）によって記憶された前記履歴に基づいて、ユーザのゲーム画面に登場した、当該ユーザと仲間関係にない同一の他のユーザに関する情報が所定回数以上になったと判断した場合に、当該他のユーザを仲間候補として前記ユーザに薦める推薦手段（52）、として機能させるためのプログラムである。

本発明によれば、ゲーム管理装置側からユーザに対して、仲間関係構築のマッチングを積極的に仕掛け、ユーザにとって関心の持てる相手に対して、手間を掛けることなく円滑に仲間申請することを可能にする。

本発明の一実施の形態に係るゲームシステムの構成例を示す説明図である。 ゲーム管理装置のハード構成の一例を示すブロック図である。 端末装置のハード構成の一例を示すブロック図である。 ゲームのメイン画面の一例を示す説明図である。 仲間候補リスト画面の一例を示す説明図である。 対戦相手選択画面の一例を示す説明図である。 対戦プレイ画面の一例を示す説明図である。 ゲームサーバが仲間候補をユーザに薦める画面の一例を示す説明図である。 ゲーム管理装置の基本的な機能的構成の一例を示す機能ブロック図である。 ユーザのゲームに関する情報の一例を示す説明図である。 ゲーム管理装置の主要な機能的構成の一例を示す機能ブロック図である。 ユーザのゲーム画面に登場した他のユーザに関する情報の履歴の一例を示す説明図である。 ゲームサーバが仲間候補をユーザに薦める画面の他の例を示す説明図である。 ゲームサーバ側からユーザに対して、仲間関係構築のマッチングを積極的に仕掛ける基本的な動作例を示すフローチャートである。 ゲーム管理装置の主要な機能的構成の他の例を示す機能ブロック図である。 ゲームサーバによるライバル候補（仲間候補）の選択動作の一例を示すフローチャートである。 ゲームサーバ側からユーザに対して、仲間関係構築のマッチングを積極的に仕掛ける動作の他の例を示すフローチャートである。 ゲームサーバが仲間候補をユーザに薦める画面の他の例を示す説明図である。 ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。 ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。 対戦開始画面の一例を示す説明図である。 仲間以外の助っ人選択画面の一例を示す説明図である。 助っ人が設定された対戦開始画面の一例を示す説明図である。 ゲームサーバが仲間候補をユーザに薦める画面の他の例を示す説明図である。 コミュニティルーム内の画面の一例を示す説明図である。

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

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

本実施の形態のネットワーク４は、インターネットに限定されるものではなく、ゲームサーバ１と各ユーザの端末装置３との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線（電話回線、移動体通信回線等）、有線ＬＡＮ（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）ディスプレイ等の既知の種々の表示装置が適用できる。

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

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

操作入力部４０は、ユーザの操作入力を受け入れて当該操作入力に対応した入力信号を、バスライン４２を介してＣＰＵ３１に出力するものである。操作入力部４０の例としては、キーボードやマウス等のポインティングデバイスがある。また、表示部３５の画面にタッチパネル（接触入力式のインタフェース）を搭載することによって表示部３５をいわゆるタッチスクリーンとして構成している端末装置３の場合、当該タッチパネルも操作入力部４０となる。

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

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

〔ゲームの説明〕
本実施の形態では、ユーザがゲーム内においてＭＬＢの実在選手に対応する選手キャラクタを所有し、当該選手キャラクタを用いて自分のチームをつくる野球ゲームを例に挙げる。

ユーザが所有する選手キャラクタは、当該選手キャラクタの形態を端末装置３の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手キャラクタとしてゲームサーバ１で管理されるとともに、ユーザの端末装置３の画面に表示される。また、選手キャラクタは、ゲーム内での試合等において、３次元コンピュータグラフィックスにより描写してもよい。また、ストリーミング形式等により、選手キャラクタやボールオブジェクト等を動画表示してもよい。ユーザは、ゲームを進行させながら選手キャラクタを集め、自分だけのオリジナルチームを結成し、他のユーザと対戦することができる。ユーザの選手キャラクタは、ＭＬＢの実在選手に対応しているので、仮想的にＭＬＢで活躍する選手による自分だけのドリームチームをつくってゲームを楽しむ。また、ユーザは、集めた選手キャラクタ同士を合成することによって、選手キャラクタの能力を向上させる（すなわち、キャラクタを育成する）ことができ、より強いチーム作りを目指してゲームを楽しむ。

選手キャラクタには、「個別能力」、「コスト」、「調子」、「成績」等のパラメータが設定されている。選手キャラクタが野手の場合の個別能力としては、「打撃」、「走力」、「守備」等とすることができる。また、選手キャラクタが投手の場合には、「球威」、「制球」、「変化」等とすることができる。また、各選手キャラクタには能力の高さに応じた「コスト」というパラメータ（属性）が設定される。ユーザは、自分のチームをつくるとき、最大総コストの範囲内で、選手キャラクタをロスター設定しなければならない。ここで「ロスター」とは、ゲーム内の対戦に出場できる登録選手（一軍登録選手）キャラクタのことである。なお、「ロスター」に代えて「デッキ」等の他の表現を用いてもよい。

また、各選手キャラクタには、能力をどの程度発揮できるかを決定するための「調子」というパラメータが設定される。この調子によって、選手キャラクタの持つ能力が、例えば２０％〜１００％の範囲で調整される。また、選手キャラクタが野手の場合には、「打率」、「打点」、「本塁打」等の成績のパラメータも設定される。なお、選手キャラクタが投手の場合には、「防御率」、「勝ち数」、「負け数」等の成績のパラメータが設定される。各選手キャラクタに設定されるこれらの各種パラメータは、実在選手の現実世界での実際の活躍・成績に応じて更新される。

図４に、本ゲームのメイン画面（マイページ）の一例を示す。このメイン画面には、ユーザのゲーム情報８１（ユーザの写真またはアバター、ユーザのゲームレベル、行動力ポイント、総コスト、選手キャラクタの数、各種ゲーム内ポイント、仲間人数など）が表示される。また、メイン画面には、対戦ボタン８３、コミュニティ入室ボタン８４等の、各種モードを選択するためのボタン群８２が表示される。

また、本ゲームでは、ユーザ同士が仲間関係を構築することができる。ここで、仲間関係とは、ゲーム内で構築されるプレイヤ同士の仮想的な関係の総称であり、知人、友人、友達、クラスメイト、相棒、親類、家族、兄弟、姉妹、会社や組織の同僚などの様々なゲーム内の関係を含む。本ゲームでは、仲間の関係にある２人の交流の回数または頻度が大きくなるほど２人の親密度が高くなり、それに伴って、知り合い、友人、親友、相棒、盟友と段階的に関係が変化する。

メイン画面には、ユーザの仲間の表示領域８５が設けられ、仲間の写真またはアバターが所定数表示される。なお、この仲間の表示領域８５の左右に設けられている方向キー８６を押すことにより、表示されていない仲間の写真等を表示させることができる。さらに、メイン画面には、テキスト表示領域８７も設けられ、仲間に関する最新情報等を確認できるようになっている。

あるユーザが他のユーザと仲間関係を構築するための一形態としては、２人のユーザの何れか一方が、他方のユーザに対してゲームサーバ１を介して仲間申請を行い、当該仲間申請を受けたユーザがゲームサーバ１を介して仲間になることを承認するという、両ユーザ間においてなされる仲間申請とその承認の操作が挙げられる。その他の形態としては、既にゲームサービスに登録済みのユーザが、未登録のユーザをゲームに招待し、招待を受けたユーザがゲームサービスに登録した場合に、招待した側とされた側との２人のユーザを仲間同士とする形態もある。

本実施の形態のゲームでは、ユーザが他のユーザに仲間申請する形態としては、主に２つの形態がある。その１つは、ユーザが自主的に仲間を作るための操作を行うことにより、画面に仲間候補リストを表示させ、その中からユーザが仲間になりたい相手を選択して仲間申請する形態である。この形態の一例を以下に説明する。

新しい仲間を探しているユーザは、自分の端末装置３で仲間候補リストを表示させるための入力（例えば、図示しない「新しい仲間を探す」ボタンを押す操作）を行う。ゲームサーバ１は、ユーザによる前記入力に関する情報に応じて、仲間候補のユーザを抽出する処理を実行し、図５に例示する仲間候補リストをユーザの端末装置３の画面へ表示させる。この仲間候補リスト画面には、所定数（図５では４つ）の仲間候補表示領域１５１が設けられている。そして、各仲間候補表示領域１５１には、仲間候補のユーザのアバター（または写真）、名前、ゲームレベル等が表示される。ユーザは、仲間候補リスト内に表示されている仲間候補の情報を見て、仲間の申請をする相手を探す。なお、仲間候補のアバター又は名前をクリックすることにより、当該仲間候補に関するより詳細な情報を表示する画面に遷移するようにしてもよい。もしもユーザが仲間になりたいと思える相手が仲間候補リストに含まれていなければ、更新ボタン１５２を押せばよい。これにより、ゲームサーバ１が、改めて仲間候補を抽出し、仲間候補リストを更新する。

また、各仲間候補表示領域１５１には、申請ボタン１５３が設けられている。仲間候補リストの中に、ユーザが仲間になりたいと思える相手がいた場合、ユーザはその相手の申請ボタン１５３をクリックすることにより、仲間の申請を行うことができる。なお、申請ボタン１５３がクリックされた場合、図示しないメッセージ入力画面に遷移して、仲間申請の際に添付する任意のメッセージを入力した上で、仲間申請することができるようにしてもよい。

ユーザが他のユーザに仲間申請するもう一つの形態は、ゲームサーバ１側からユーザＡに対して、特定の他のユーザＢを仲間候補としてユーザＡに薦め、それにユーザＡが応えることにより仲間申請できるというものである。この形態の一例を以下に説明する。

ユーザＡは、メイン画面内の対戦ボタン８３を選択することにより、他のユーザと対戦（本実施の形態では野球の試合）を行うことができる。ユーザＡが対戦ボタン８３を選択すれば、図６の対戦相手選択画面に遷移する。この画面にはゲームサーバ１によって選択された所定数（図６では４人）の対戦相手候補がリスト表示される。対戦相手候補の情報表示領域１５１には、対戦相手候補の写真またはアバター、名前、レベル、総コスト、対戦成績等が表示される。ここで、ユーザＡのゲーム画面に表示される対戦相手候補は、ゲームサーバ１によって以下のようにして選択される。

ユーザＡが対戦を行っていく中で、ゲームサーバ１側で、過去の対戦相手の中から所定の基準に基づき、「ライバル候補」（仲間候補となり得る第２のユーザ）が選択される。例えば、直近２０試合の対戦相手の中から、「ライバル候補」が所定数（例えば５人以内で）選択される。その選択基準としては、例えば下記のような基準またはそれらの組み合わせを採用することができる。

（Ａ）ゲームへのアクセス頻度（１日１回なのか、３日に１回程度なのか）、対戦頻度、勝率、仲間数、ゲーム開始日時、年齢、レベル等が、ユーザＡと同一またはその違いが所定範囲内

（Ｂ）対戦結果が拮抗していた（例えば得点差が２点以内であった）
（Ｃ）ゲーム上の設定チームが異なる（但し、リーグは同じ）

上記（Ａ）の基準は、ユーザＡとの共通性に着目したものである。ユーザＡと共通性を有する他のユーザは、将来、仲間候補として推薦された場合に、ユーザＡから関心を持たれ易い。前記レベルはゲーム内での進捗度、技術の度合い等を示し、ゲームによってはステージや、段位、称号等と呼称されるものも含む。上記（Ｂ）および（Ｃ）の基準は、ライバルとしての適性に基づくものである。過去の対戦で接戦を演じた相手はライバルとして相応しい。また、各ユーザは、現実世界のＭＬＢの３０チームの中から好きなチームを１つ選択して自分のチームに設定する。ライバルという観点からは、ユーザが設定したチーム以外のチーム（但し、同一リーグ）の他のユーザが相応しい。

直近の所定試合（例えば２０試合）の対戦相手の中から「ライバル候補」を選択する理由は、例えば数百試合も前に遡った対戦の相手についてはユーザの記憶に残っていないことも多いが、直近の２０試合程度であれば、ユーザが過去に対戦したことを覚えている可能性が高く、ライバルとして（且つ仲間候補として）関心を持ち易いことによる。直近の所定試合の中から「ライバル候補」を選択する代わりに、現在より遡る所定期間内（例えば１か月以内）の対戦相手の中から、上述の選択基準に基づいて「ライバル候補」を選択してもよい。

ゲームサーバ１は、上記のようにして「ライバル候補」を選択した後、図６に例示する対戦相手候補リストに、「ライバル候補」の一部または全員を入れ、ユーザＡから対戦相手として選択され易いようにする。すなわち、ゲームサーバ１によって選択された「ライバル候補」は、「ライバル候補」として選択されなかった他のユーザよりも、ユーザＡの対戦相手候補としてリスト表示され易くなる。例えば、「ライバル候補」は２０％の確率で対戦相手候補リストに表示され、その他のユーザが対戦相手候補リストに表示される確率を１％以下とする。よって、「ライバル候補」として選択されたユーザＢ（Ｃ、Ｄ…）は、「ライバル候補」として選択されなかった他のユーザよりも、ユーザＡの対戦相手選択画面に登場する頻度が高くなる。ここで、図６に示すように、「ライバル候補」として選択され、且つ、ユーザＡの画面に表示された該当のユーザには、「ライバル候補」という表示１５７を付しても良い。

あるいは、ユーザＡの「ライバル」（後述する）となった他のユーザが、対戦相手候補リストに優先的に（例えばリストの上位に）表示されるようにしてもよい。

対戦相手選択画面において、ユーザＡは、対戦相手候補リストの中から、対戦したい相手を１人選んで決定ボタン１５６を押せば、図７に例示する対戦プレイ画面に遷移する。このゲーム画面の左側には、ユーザＡのチームのロスター１５８が並べられ、画面の右側には対戦相手のチームのロスター１５９が並べられる。また、打席に立っている選手キャラクタ１６０、および投球している選手キャラクタ１６１は、それぞれハイライトで表示される。また、画面内には、スコアボード１６２が表示されて得点経過が確認できるとともに、走者アイコン１６３が表示されて出塁状況も確認できる。また、対戦プレイ中のゲーム画面内には、テキスト表示領域１６４が設けられ、対戦プレイのシミュレーションのゲーム結果や現在の試合状況が簡潔な文章で表示される。得点圏に走者が出る等のチャンスの場面になれば、ストリーミング映像が表示されるようにしてもよい。

ここで、ユーザＡによって同一の「ライバル候補」（例えばユーザＢ）が所定回数以上（例えば３回以上）、対戦相手として選択された場合には、その「ライバル候補」は「ライバル」に設定される。

ユーザにとって「ライバル」は、対戦を重ね、かなり関心を引く存在になっていることから、ゲームサーバ１側から、「ライバル」に設定されたユーザＢがユーザＡの仲間になる切っ掛けを与える。例えば、図８に例示するように、ユーザＡのゲーム中の画面内にサブウインドウ１６５が表示され、架空のキャラクタ１６６がユーザＡに対して「ライバル」であるユーザＢと仲間になってはどうかと話かけるような演出を行う。図８では、テキスト表示領域１６７に、「Ｂさんとはこれで３回目の対戦ですね。Ｂさんはあなたのライバルに認定されました。ライバルのＢさんと仲間になってはどうですか？」というメッセージが表示される例を示している。

また、このとき、ゲームサーバ１が仲間候補として推薦する他のユーザ（図８の例ではユーザＢ）に関する情報表示領域１６８および仲間申請ボタン１６９も併せて表示される。情報表示領域１６８には、例えばユーザＢの写真またはアバター、名前、レベル、総コスト、トータルの勝敗、ユーザＡとの対戦の勝敗等が表示される。ここで、ユーザＡが仲間申請ボタン１６９を押せば、ゲームサーバ１から薦められたユーザＢに対して仲間申請を行うことができる。

また、並行して、「ライバル」側のユーザＢにも、ユーザＡと仲間になるように、ゲームサーバ１から積極的に薦める働きかけをしてもよい。

なお、ユーザＡが薦められたユーザＢに対して仲間申請したくない場合、閉じるボタン１７０を押せば、サブウインドウ１６５が閉じられる。

上記のように、本実施の形態では、ユーザＡが自主的に仲間を作るための操作を行ったときにだけ、ランダムに仲間候補リストを表示するだけではなく、ゲームサーバ１側からユーザＡに対して、仲間関係構築のマッチングを積極的に仕掛け、ユーザＡのゲーム画面に所定回数以上登場した他のユーザＢを仲間候補としてユーザＡに薦める。すなわち、ユーザＡがゲームをプレイする中で、「ライバル候補」→「ライバル」→「仲間」となる自然な流れをゲーム管理装置が作り出し（そのような流れになるようにゲーム管理装置がサポートし）、仲間作りの導線とする。

上記では、ユーザＡと仲間になっていない他のユーザの中から所定の選択基準を満たすユーザＢ（Ｃ、Ｄ…）を「ライバル候補」として選択し、このユーザＢ（Ｃ、Ｄ…）がユーザＡのゲーム画面（対戦相手候補リスト）に登場する頻度をゲームサーバ１が意図的に高める処理を実行している。このような処理に依らず、偶然、ユーザＡの画面に同じ対戦相手が複数回登場するケースもあり得、その場合でもユーザＡはその相手に関心を持つ可能性がある。そこで、ユーザＡの画面に他の同一ユーザＢが複数回登場した場合に、ゲームサーバ１側からユーザＡに対して、ユーザＢを仲間候補として薦めるようにしてもよい。

〔ゲーム管理装置の機能的構成および動作〕
次に、上記の野球ゲームを実現するゲーム管理装置の機能的構成の一例について説明する。図９は、端末装置３と通信するゲーム管理装置（ゲームサーバ１およびデータベースサーバ２）の基本的な構成を示す機能ブロック図である。

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

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

ユーザ情報記憶制御手段６０は、各ユーザを一意に識別するユーザＩＤと対応付けて、ログインＩＤ、パスワード、ユーザ名（ゲーム内で使用するニックネーム等）、チーム等の各ユーザに関する基本情報を、データベースサーバ２の所定の記憶領域に記憶する。ここで、ログインＩＤおよびパスワードは、各ユーザが端末装置３を操作してゲームサーバ１にアクセスしたときのログイン認証に用いられる。ユーザ名およびチームは、ユーザがゲームサービスを受けるための利用登録をした際や、ゲームを初めて実行した際に、ユーザが自ら設定した任意の情報である。ユーザ名およびチームは、必要に応じてゲーム画面に表示される。

また、ユーザ情報記憶制御手段６０は、ユーザＩＤと対応付けて、ユーザのゲームレベルの情報を、データベースサーバ２の所定の記憶領域に記憶する。本野球ゲームでは、例えば、ユーザがゲームを進行させることにより経験値が蓄積され、当該経験値が一定量に達することによりユーザのレベルがアップするようになっている。

また、ユーザ情報記憶制御手段６０は、ユーザＩＤと対応付けて、ゲーム内でユーザが入手して所有している選手キャラクタの情報を、ユーザＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。また、データベースサーバ２には、選手ＩＤと対応付けられて、選手キャラクタの画像データ、選手名、ポジション、所属球団、能力値、コストなどが記憶された選手データベース（選手ＤＢ）が存在し、ゲームサーバ１は、ユーザ情報記憶制御手段６０によって記憶されている選手ＩＤに基づいて、当該選手ＩＤに対応する選手キャラクタの画像データ等を取得できるようになっている。

また、ユーザ情報記憶制御手段６０は、ユーザＩＤと対応付けて、ゲーム内でユーザが所有している各種ポイント（ポイントに準ずる値などを含む）およびアイテムをデータベースサーバ２の所定の記憶領域に記憶する。

また、ユーザ情報記憶制御手段６０は、ユーザＩＤと対応付けて、ユーザのチームが他のユーザのチームと対戦した結果を一意に特定するための対戦ＩＤを、データベースサーバ２の所定の記憶領域に記憶する。また、データベースサーバ２は、対戦ＩＤと対応付けられて、対戦日時、勝利したチームのユーザＩＤ、敗北したチームのユーザＩＤ、対戦スコア、勝利投手キャラクタ、敗戦投手キャラクタ、本塁打を打った選手キャラクタ、対戦寸評情報などの対戦結果に関する情報が記憶された対戦データベースを備えている。よって、各ユーザの過去の対戦結果については、対戦データベースから取得できるようになっている。

また、ユーザ情報記憶制御手段６０は、ユーザＩＤと対応付けて、仲間のユーザＩＤをデータベースサーバ２の所定領域に記憶する。また、ユーザ情報記憶制御手段６０は、ユーザＩＤと対応付けて、上述のライバル候補として選択された他のユーザのユーザＩＤをデータベースサーバ２の所定領域に記憶する。また、各ライバル候補に対応付けて、ユーザ（ユーザＩＤ＝０００００１）との対戦回数を併せて記憶している。また、ユーザ情報記憶制御手段６０は、ユーザＩＤと対応付けて、上述のライバルとして認定した他のユーザのユーザＩＤをデータベースサーバ２の所定領域に記憶する。

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

ユーザの端末装置３のウェブブラウザによってゲーム画面が表示されているとき、ユーザがゲーム画面上の選択可能なボタンオブジェクトやハイパーリンクが設定された文字列等を選択する入力の操作を行った場合、当該入力に関する情報（ゲーム画面のリクエスト等）が端末装置３のウェブブラウザによってゲームサーバ１へ送信される。ゲームサーバ１では、前記入力に関する情報を受信手段６１が受信したとき、ゲーム実行手段６２が、当該情報に応じてユーザのゲームに関する情報を読み出して演算やデータ処理を行うことによってゲームを実行する。

例えば、対戦モードで他のユーザのチームと対戦するという入力操作がユーザによって行われた場合を例に挙げると、ゲーム実行手段６２は、対戦を行う両ユーザのユーザＩＤに対応した両チームの選手キャラクタ（試合に出場するキャラクタ）の情報をデータベースサーバ２から読み出す。そして、ゲーム実行手段６２は、ＡＩ（Artificial Intelligence）プログラム等により、両チームの選手キャラクタの能力等のパラメータに基づいて、野球の試合のシミュレーションを実行し、試合の勝敗を決定する。

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

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

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

次に、図１１の機能ブロック図を参照して、ゲーム管理装置（ゲームサーバ１およびデータベースサーバ２）の主要な機能的構成について説明する。ゲーム管理装置としてのゲームサーバ１は、主に、履歴記憶制御手段５１および推薦手段５２を備えている。これらの各手段は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

履歴記憶制御手段５１は、ユーザのゲーム画面に登場した他のユーザに関する情報の履歴を記憶装置（データベースサーバ２等）に記憶する機能を有する。ここで、「他のユーザに関する情報」の例としては、図６に示すように、他のユーザのアバター、写真、名前（ニックネームであってもよい）などを挙げることができる。その他にも、対戦相手や協力プレイ相手としてユーザの画面に登場する、他のユーザの分身的キャラクタ（いわゆるプレイヤキャラクタ）、他のユーザが所有するキャラクタ（野球ゲームでは、他のユーザのチームに所属する選手キャラクタ）等であってもよい。あるいは、後述するように、ユーザのチャット相手等としてユーザの画面に他のユーザが登場する場合もある。これらに限らず、他のユーザに関する情報がユーザのゲーム画面に登場する態様は、ゲームの種類や内容により様々である。本実施の形態では、ユーザの対戦相手または対戦相手候補として、他のユーザがユーザのゲーム画面に登場する場合を中心に説明する。

履歴記憶制御手段５１がデータベースサーバ２に記憶している、ユーザのゲーム画面に登場した他のユーザに関する情報の履歴の一例を、図１２に例示する。同図では、ユーザＩＤ＝０００００１のユーザＡについての情報を示している。同図に示すように、履歴記憶制御手段５１は、ユーザＡのユーザＩＤと対応付けて、ユーザＡのゲーム画面に登場した他のユーザのユーザＩＤ、ステータスフラグ、時間情報等をデータベースサーバ２に記憶する。

ここで、ステータスフラグとは、ユーザＡの対戦相手候補としてのみゲーム画面に登場した他のユーザ（フラグ＝０）であるか、ユーザＡに対戦相手として選択されて実際にゲーム内でユーザと接点を持った他のユーザ（フラグ＝１）であるかを識別するための情報である。対戦相手候補としてユーザＡのゲーム画面に登場した他のユーザは、対戦相手とすべきか否かについて、ある程度の注目度をもってユーザＡによって検討をされている。よって、対戦相手候補としてユーザＡのゲーム画面に登場しただけでも、ユーザＡに関心を持たれ易い存在となり得る。しかし、通常、単に対戦相手候補としてユーザＡのゲーム画面に登場しただけの他のユーザよりも、候補リストの中からユーザＡによって選択されて実際にユーザＡと直接的にゲーム内で接点を持った他のユーザの方が、ユーザＡにとっては印象深く関心を引く存在となっていると考えられる。よって、ユーザＡのゲーム画面に登場した他のユーザが、対戦相手候補にとどまるのか、ユーザＡに対戦相手として選択されたのかによって、処理内容を異ならせる場合に、ステータスフラグの情報を使用することができる（その詳細は後述する）。なお、対戦相手候補および対戦相手の両方を、ユーザＡのゲーム画面に登場した他のユーザとして同様に扱う場合には、このステータスフラグの情報を省略することもできる。

なお、対戦相手候補としてユーザＡのゲーム画面（対戦相手候補リスト画面）に登場し、その中からユーザＡに対戦相手として選択されて対戦した他のユーザは、対戦相手候補および対戦相手としてユーザＡのゲーム画面に登場する。この場合、一連の流れの中で対戦相手候補から対戦相手になるので、ユーザＡのゲーム画面への登場回数としては原則１回としてカウントされる。また、対戦ゲーム中（野球ゲームの試合中）には、他のユーザの所有する選手キャラクタが、複数回、ユーザＡの画面に登場するが、同一の試合中であれば何度登場したとしても、登場回数としては原則１回としてカウントされる。すなわち、ユーザＡが他のユーザＢと対戦を行う場合、ユーザＡのゲーム画面に登場するユーザＢに関する情報としては、対戦相手候補として表示されるユーザＢのアバター等、対戦相手として表示されるユーザＢのアバター等、対戦プレイ中に表示されるユーザＢの選手キャラクタ等があるが、ユーザＡのゲーム画面へのユーザＢの登場回数としては原則１回となる。なお、これを登場回数が３回とすることも可能である。

次に、推薦手段５２について説明する。この推薦手段５２は、前記履歴記憶制御手段５１によってデータベースサーバ２に記憶された前記履歴に基づいて、ユーザのゲーム画面に登場した、当該ユーザと仲間関係にない同一の他のユーザに関する情報が所定回数以上になったと判断した場合に、当該他のユーザを仲間候補として前記ユーザに薦める機能を有する。ここで、所定回数としては、例えば３回、５回等、任意に設定することができる。ユーザＡにとって、自分のゲーム画面に何度も登場した他のユーザＢについては、関心を引く存在になっていると考えられる。そこで、ユーザＡの画面に登場した他のユーザＢの回数が所定回数以上になり、ユーザＡが他のユーザＢに関心を持ったころに、タイミングよく、ゲームサーバ１が、他のユーザＢを仲間候補としてユーザＡに薦めるのである。

推薦手段５２による推薦処理によってユーザＡの端末装置３に表示される画面例を、図８および図１３に示す。図８は、前述のように、ユーザＡの対戦プレイ画面に、他のユーザＢが所定回数以上（例えば３回以上）、対戦相手として登場したときに表示される画面例である。また、図１３は、ユーザＡの対戦相手選択画面において、他のユーザＢが所定回数以上（例えば５回以上）登場したときに表示される画面例である。

この図１３の画面でも図８と同様に、画面内にサブウインドウ１６５が表示され、架空のキャラクタ１６６がユーザＡに対してユーザＢと仲間になってはどうかと話かけるような演出を行う。図１３では、テキスト表示領域１６７に、「最近、Ｂさんが、あなたのゲーム画面によく登場しますね。この機会にＢさんと仲間になってはどうですか？」というメッセージが表示される例を示している。このように、ユーザＡの画面に、他のユーザＢが対戦相手候補として登場した段階で、他のユーザＢを仲間候補としてユーザＡに薦めてもよい。

上述のように、単に対戦相手候補としてユーザＡのゲーム画面に登場しただけの他のユーザよりも、実際にユーザＡと対戦してゲーム内で接点を持った他のユーザの方が、ユーザにとっては印象深く関心を引く存在となっている。そこで、ユーザＡのゲーム画面に対戦相手として登場した場合の前記所定回数と、ユーザＡのゲーム画面に対戦相手候補として登場した場合（または対戦相手候補と対戦相手とが混在している場合）の前記所定回数とを異ならせても良い。すなわち、前者の所定回数の方が後者の所定回数よりも小さくする。例えば、ユーザＡのゲーム画面に同一の他のユーザＢが対戦相手として登場するならば、３回以上の登場をもって仲間候補として推薦される。これに対して、ユーザＡのゲーム画面に同一の他のユーザＢが対戦相手候補として登場する（または対戦相手候補と対戦相手とが混在している）ならば、例えば５回以上の登場をもって仲間候補として推薦される。

ところで、ユーザＡのゲーム画面に他のユーザＢが登場する回数が所定回数（例えば３回）に達するまでに長期間を要することもある。例えば、最初に登場してから１年以上かけてやっと登場回数が３回に達するような場合である。あるいは、２回目の登場から３回目の登場までに１年以上も期間が空いてしまう場合である。このような場合、ユーザＡにとって、過去に自分の画面に登場した他のユーザＢについての記憶は薄れていると考えられる。そこで、推薦手段５２は、現在から遡る所定期間内（例えば１か月以内）という条件の中で、ユーザＡのゲーム画面に登場した同一の他のユーザＢに関する情報が所定回数以上になったと判断した場合に、当該他のユーザＢを仲間候補としてユーザＡに薦めることとすることが好ましい。

ここで、ゲームサーバ１側からユーザＡに対して、仲間関係構築のマッチングを積極的に仕掛ける基本的な動作例を、図１４のフローチャートに示す。

ゲームサーバ１は、ユーザＡのゲーム画面に、他のユーザのアバター等が登場した場合（Ｓ１でＹＥＳ）、ユーザＡのゲーム画面に登場した他のユーザに関する情報の履歴をデータベースサーバ２に記憶する（Ｓ２）。これにより、例えば、図１２に例示するように、ユーザＡのユーザＩＤと対応付けて、ゲーム画面に登場した他のユーザのユーザＩＤ等が履歴として記憶される。

その後、ゲームサーバ１は、データベースサーバ２に記憶されている図１２の履歴に基づいて、ユーザＡと仲間関係にない同一の他のユーザのゲーム画面への登場回数が、所定回数以上になったか否かを判断する（Ｓ３）。ここで、ゲームサーバ１は、同一の他のユーザ（例えばユーザＢとする）の登場回数が所定回数以上になったと判断した場合（Ｓ３でＹＥＳ）、当該ユーザＢを仲間候補としてユーザＡに薦める（Ｓ４）。例えば、図８または図１３に例示するように、架空のキャラクタ１６６がユーザＡに対してユーザＢと仲間になってはどうかと話かけるような演出を行う。

ここで、ユーザＡが、ゲームサーバ１側からの積極的な仲間候補の推薦に応えて、仲間申請のための入力を行った場合、例えば、図１３の仲間申請ボタン１６９をクリックした場合（Ｓ５でＹＥＳ）、ゲームサーバ１は、当該入力に応じて仲間申請処理を実行する（Ｓ６）。すなわち、ゲームサーバ１は、ユーザＡが仲間申請したユーザＢに対して、ユーザＡから仲間申請があった旨を通知する。

なお、仲間申請を受けたユーザＢは、ゲームサーバ１から受信したユーザＡのゲームレベル等の情報を、端末装置３の画面上で確認し、仲間として承認するか拒否するかを選択する操作を行うことができる。ここで、ユーザＢが仲間として承認する操作を行った場合、この操作に応じてゲームサーバ１は、ユーザＡとユーザＢとの仲間関係を成立させ、両ユーザＡ・ＢのユーザＩＤを関係付けた仲間情報をデータベースサーバ２に登録する。例えば、図１０に示すように、ユーザＡの情報を記憶するデータベースにおいて、ユーザＡのユーザＩＤと対応付けて、ユーザＢのユーザＩＤを仲間情報として記憶する。同様に、図示しないユーザＢの情報を記憶するデータベースにおいて、ユーザＢのユーザＩＤと対仲間関係が成立したユーザＡ・Ｂの各端末装置３に、仲間成立の旨を報知する。

一方、ステップＳ３において、同一の他のユーザのユーザＡの画面への登場回数が所定回数に満たなかった場合（Ｓ３でＮＯ）、仲間候補の推薦処理を実行することなく処理を終える。

ユーザＡにとって、自分のゲーム画面に何度も登場した他のユーザＢについては、関心を引く存在になっていると考えられる。そこで、本実施の形態のゲームサーバ１は、ユーザＡが自主的に仲間を作るための操作を行ったときにだけ、ランダムに仲間候補リストを表示するだけではなく、ゲームサーバ１側からユーザＡに対して、仲間関係構築のマッチングを積極的に仕掛け、他のユーザＢを仲間候補としてユーザＡに薦める。

また、図５に示すように、ランダムに抽出された仲間候補リストの中から仲間になりたい相手を探す場合、ユーザＡにとって関心のある相手が仲間候補リストに含まれておらず、何度も仲間候補リストを更新しながら、ユーザＡが手間を掛けて、仲間になりたい相手を探すことも多かった。これに対して、本構成では、ユーザＡの画面に登場した他のユーザＢの回数が所定回数以上になり、ユーザＡが他のユーザＢに関心を持ったころに、タイミングよくゲームサーバ１側から他のユーザＢを仲間候補としてユーザＡに薦めるので、ユーザＡはゲームをしながら手間を掛けることなく円滑に仲間をつくることができるようになる。

ところで、推薦手段５２は、ユーザＡのゲーム画面に、偶然、他のユーザＢが複数回登場した場合にも、あるいは以下に説明するように、ゲームサーバ１が所定基準を満たす他のユーザＢのゲーム画面への登場頻度を高めた結果として、他のユーザＢが複数回登場した場合の何れでも、他のユーザＢを仲間候補としてユーザＡに薦めることができる。

ユーザＡが対戦を行う場合の対戦相手候補の選択については、ユーザＡの強さの指標となる値（ゲームレベルまたはユーザＡのチームの総コスト等）を基準とした所定範囲内の他のユーザの中から、ランダムに選択することができる。すなわち、ユーザＡの強さと極端な開きがない他のユーザの中から、対戦相手候補をランダムに選択することができる。この場合であっても、ユーザＡのゲーム画面に同一の他のユーザＢが対戦相手候補として（またはユーザＡに選択されて対戦相手として）、所定回数以上登場することもある。ただし、偶然（ランダム）に任せていると、特にゲームに登録しているユーザ数が数万人以上と多い場合は、所定回数の登場までに長時間がかかる（または所定回数登場する確率が極めて低くなる）こともあり得る。

そこで、ユーザＡ（第１のユーザ）と仲間になっていない他のユーザの中から所定の選択基準を満たすユーザＢ（Ｃ、Ｄ…）（第２のユーザ）を選択し、ユーザＢ（Ｃ、Ｄ…）がユーザＡのゲーム画面に登場する頻度を高める構成が好ましい。これを実現するゲームサーバ１は、図１５に示すように、履歴記憶制御手段５１および推薦手段５２の他に、選択手段５３および相手管理手段５４をさらに備える。

選択手段５３は、第１のユーザＡと仲間関係にない他のユーザの中から、所定の選択基準に基づいて、仲間候補となり得る第２のユーザＢ（Ｃ、Ｄ…）を選択する機能を有する。この機能は、対戦モードにおいて、前述の「ライバル候補」を選択する機能に該当する。

ここで、前記選択基準としては、出来るだけ第１のユーザＡが関心を持ちそうな第２のユーザが抽出できるようなものとすることが好ましい。選択基準の例としては、前述のように、ゲームへのアクセス頻度、仲間数、ゲーム開始日時、年齢、レベルなどが第１のユーザＡと同一またはその違いが所定範囲内とすることができる。また、本実施の形態のような対戦ゲームにおける選択基準としては、対戦頻度、勝率などが第１のユーザＡと同一またはその違いが所定範囲内とすることができる。また、第１のユーザＡの直近の所定試合（例えば２０試合）の対戦相手という選択基準や、現在から遡る１か月以内の対戦相手という選択基準を適用することができる。さらに、本実施の形態のゲームのように、仲間候補となり得る第２のユーザを、対戦のライバル候補として位置付ける場合、前述のように、対戦結果が拮抗していた（例えば得点差が２点以内であった）、ゲーム上の設定チームが異なる（但し、リーグは同じ）等の選択基準を適用することもできる。

また、選択基準は、上記のような各基準を単独で、または種々組み合わせて採用することができる。なお、これらは一例であり、ゲームの種類や内容に応じて様々な選択基準を適用できる。

選択手段５３が、ライバル候補（仲間候補）を選択する処理を実行するタイミングは、任意に定めることができる。例えば、第１のユーザＡが対戦を行う毎に、ライバル候補を選択する（更新する）ようにしてもよい。あるいは、ライバル候補の選択は１日に１回とし、ある日の最初の対戦時にライバル候補を選択すれば、その日の２戦目以降も、同じライバル候補が適用されるようにしてもよい。あるいは、ライバル候補の選択は、３日に１回、１週間に１回等としてもよい。

図１０に例示するように、選択手段５３によってライバル候補（仲間候補）として選択された第２のユーザＢ（Ｃ、Ｄ…）のユーザＩＤは、第１のユーザＡのユーザＩＤと対応付けてデータベースサーバ２に記憶される。

次に、相手管理手段５４について説明する。この相手管理手段５４は、前記選択手段５３によって選択された第２のユーザＢ（Ｃ、Ｄ…）に関する情報を、第１のユーザＡのゲームプレイの相手または相手候補として、第１のユーザＡのゲーム中の画面に登場させる頻度を、第２のユーザＢ（Ｃ、Ｄ…）以外の他のユーザに関する情報よりも高くする機能を有する。ここで、「ゲームプレイの相手または相手候補」とは、例えば、対戦相手、対戦相手候補の他、後述する協力プレイ相手（対戦協力をする助っ人、レイドボス戦の協力メンバ等）または協力プレイ相手候補などを挙げることができる。

ライバル候補（仲間候補）として選択された第２のユーザＢ（Ｃ、Ｄ…）の、第１のユーザＡのゲーム画面への登場頻度を、その他のユーザよりも高くする一例を以下に示す。

図６に示すように、第１のユーザＡが対戦を行うときに表示される対戦相手候補リストには、例えば４人の対戦相手候補が表示されるものとする。なお、対戦相手候補リストに表示される対戦相手候補の数は、画面の大きさ等に応じて変更してもよい。また、選択手段５３によって選択されるライバル候補としての第２のユーザを、例えば５人とする（選択基準を満たすライバル候補が５人に満たない場合は、ライバル候補が４人以下となることもある）。そして、相手管理手段５４は、対戦相手候補リストに表示するユーザを決定する場合、先ず、ライバル候補である各第２のユーザについて、所定の当選確率（例えば２０％）で抽選を行い、その抽選に当選した第２のユーザを対戦相手候補リストに含める。その後、対戦相手候補リストの残りの枠について、ライバル候補以外の他のユーザの中からランダムに決定する（但し、上述のように第１のユーザＡの強さとバランスの取れる相手となるように、他のユーザの強さを制限してもよい）。この場合、ライバル候補以外の他のユーザが対戦相手候補リストの残りの枠に当選する確率は、ゲームに登録しているユーザ数にもよるが、例えば数百人以上のユーザが登録しているゲームであれば、１％以下になる。

なお、ライバル候補として選択された全ての第２のユーザを、対戦相手候補リストに常に含めるようにすることもできる。ただし、この場合、対戦相手候補リストには、いつも同じメンバばかりが表示され、第１のユーザＡにとっては、対戦相手の選択肢が狭められてしまうことになり兼ねない。ライバル候補として選択された第２のユーザが、適度な頻度でもって第１のユーザＡの対戦相手選択画面に登場し、ライバル候補以外の他のユーザについても対戦相手候補リストに含まれるように仕向けることが好ましい。

前述のように、ライバル候補としての第２のユーザを５人選出する場合に、各ライバル候補の前記当選率を２０％に設定すれば、４つある対戦相手候補リストの枠のうち、平均して１つの枠に、５人のライバル候補の何れかが表示され、残り３つの枠にはその他のユーザが表示されることになる。この程度の頻度でライバル候補がユーザのゲーム画面に登場すれば、ユーザＡにとっては対戦相手の選択時に違和感を抱くこともない。

バリエーションとしては、ｎ個ある対戦相手候補リストの枠（図６の場合４枠）のうち、ｍ個の枠（ｍ＜ｎ）を予めライバル候補（仲間候補）を表示するための枠とするとともに、（ｎ−ｍ）個の枠をライバル候補以外の他のユーザを表示するための枠としてもよい。例えば、ｍ＝１とし、４枠のうち１枠をライバル候補の表示枠として予め確保する。そして、ライバル候補の表示枠に表示するユーザを、選択手段５３によって選択された、例えば５人の第２のユーザの中からランダムに選択する。また、（ｎ−ｍ）個の枠に表示するユーザについては、ライバル候補以外の他のユーザ全体の中からランダムに選択する。

上記の例のようにして、ライバル候補として選択された第２のユーザＢ（Ｃ、Ｄ…）は、ライバル候補として選択されなかった他のユーザよりも、第１のユーザＡの対戦相手選択画面に登場する頻度が高められる。そして、図６に示すように、ライバル候補である第２のユーザＢが第１のユーザＡの画面に表示された場合には、「ライバル候補」という表示１５７を付して、第１のユーザＡの注目を引き易くすることが好ましい。

以上のように、本構成では、ゲームサーバ１が、所定の選択基準を満たす第２のユーザＢ（Ｃ、Ｄ…）の、第１のユーザＡのゲーム画面への登場頻度を高くすることで、ゲームを行う中で自然と、第１のユーザＡに第２のユーザＢ（Ｃ、Ｄ…）に対する関心を持たせ、仲間づくりへの導線とすることができる。特に、第１のユーザＡが関心を持ちそうな第２のユーザを選択できるような任意の選択基準（例えば、ゲーム開始日時、年齢、出身地等が、第１のユーザＡと同一またはその違いが所定範囲内とする第１のユーザＡとの共通性に着目した基準）を採用すれば、当該第２のユーザが仲間候補として第１のユーザＡに薦められた場合に、偶然に所定回数登場した他のユーザよりも、第１のユーザＡが関心を持つ（よって仲間になろうとする）可能性を高めることができる。

ところで、上述のように、単に対戦相手候補として第１のユーザＡのゲーム画面に登場しただけの他のユーザよりも、対戦相手候補リストの中からユーザによって選択されて実際に第１のユーザＡと直接的にゲーム内で接点を持った（対戦した）他のユーザの方が、ユーザＡにとっては印象深く関心を引く存在となっている。そこで、第１のユーザＡとゲーム内で接点を持った他のユーザを、優先的に、仲間候補となり得る第２のユーザとして選択することが好ましい。

これを実現するゲームサーバ１は、履歴記憶制御手段５１が、ユーザのゲーム画面に登場した他のユーザに関する情報のうち、少なくともユーザとゲーム内で接点を持った他のユーザに関する情報の履歴をデータベースサーバ２に記憶する。例えば、図１２に示すように、ユーザＡの対戦相手候補としてのみゲーム画面に登場した他のユーザ（フラグ＝０）であるか、ユーザＡに対戦相手として選択されて実際にゲーム内でユーザと接点を持った他のユーザ（フラグ＝１）であるかを識別するステータスフラグを、ユーザＡの画面に登場した他のユーザのユーザＩＤと対応付けて記憶する。

ここで、「ユーザとゲーム内で接点を持った他のユーザ」の例としては、対戦相手以外にも、協力プレイ相手（対戦プレイの助っ人、レイドボス戦の協力メンバ等）、ゲーム内コミュニティルームで会話（チャット）した相手などを挙げることができる。これらは一例であり、ユーザと他のユーザとがゲーム内で直接的に接点を持つ態様は、ゲームの種類や内容に応じて様々である。

そして、本実施の形態の選択手段５３は、第１のユーザＡとゲーム内で接点を持った他のユーザに関する情報の履歴に基づいて、第１のユーザＡと仲間関係にないユーザであって、過去に第１のユーザＡとゲーム内で接点を持ったことのある他のユーザを、接点を持ったことのない他のユーザよりも優先的にライバル候補（仲間候補）である第２のユーザとして選択する。

ここで、本実施の形態のゲームサーバ１によるライバル候補（仲間候補）の選択動作の一例について、図１６のフローチャートを参照しながら以下に説明する。

ゲームサーバ１の選択手段５３は、第１のユーザＡのライバル候補を選択する場合、履歴記憶制御手段５１がデータベースサーバ２に記憶している、第１のユーザＡとゲーム内で接点を持った他のユーザに関する情報の履歴に基づいて、第１のユーザＡとゲーム内で接点を持った（対戦等した）他のユーザが存在するか否かを判断する（Ｓ１１）。ここで、例えば１年以上も前に対戦等した相手については、第１のユーザＡも忘れていることも考えられるので、現在より遡る所定期間（例えば１か月）以内という時間的制限を設けてステップＳ１１の判定を行うことが好ましい。

ステップＳ１１においてＹＥＳの場合、選択手段５３は、第１のユーザＡとゲーム内で接点を持った他のユーザの中から、所定の選択基準を満たすライバル候補を選択する（Ｓ１２）。ここで選択基準としては、前述したように、直近２０試合の対戦相手という基準や、ゲームへのアクセス頻度、仲間数、ゲーム開始日時、年齢、レベルなどの基準（またはそれらの組み合わせ）を採用することができる。

その後、所定数、例えば５人のライバル候補を選択できたか否かが判断される（Ｓ１３）。例えば、第１のユーザＡが、ゲームを始めて間もないユーザであって対戦を殆ど行っていなかったり、暫くの間ゲームアクセスから遠ざかっていたユーザであったりした場合、ライバル候補としての選択基準を満たす第２のユーザが５人に満たないこともある（Ｓ１３でＮＯ）。その場合、第１のユーザＡとゲーム内で接点を持ったことのない他のユーザの中から、ゲーム開始日時、年齢等に関する選択基準を満たす者を、ライバル候補である第２のユーザとして選択する（Ｓ１４）。

また、ステップＳ１１において、第１のユーザＡとゲーム内で接点を持った他のユーザがいなかった場合にも（Ｓ１１でＮＯ）、ステップＳ１４に移行し、第１のユーザＡとゲーム内で接点を持ったことのない他のユーザの中から５人のライバル候補を選択する。

このようにして、第１のユーザＡとゲーム内で接点を持ったことのある他のユーザを、優先的にライバル候補である第２のユーザとして選択する。

本構成により、ユーザが強い関心を持つと思われる、ユーザと直接的にゲーム内で接点を持った他のユーザ（例えば候補リストの中からユーザによって選択されて実際にユーザと対戦した他のユーザ）を優先的に仲間候補として薦めることができる。よって、ゲームサーバ１から薦められた仲間候補に対して、ユーザが仲間申請する可能性を高めることができ、仲間構築の促進を図ることができる。

また、前記推薦手段５２は、ユーザＡとゲーム内で所定回数以上（例えば３回以上）接点を持ってユーザＡのゲーム画面に登場した他のユーザのみを対象として、当該ユーザＡに仲間候補として薦めるようにしてもよい。すなわち、単に候補リスト画面に登場しただけでは足りず、実際に対戦相手等として直接的な接点を持ってユーザＡの画面に所定回数以上登場することが仲間候補の条件であり、そのような仲間候補がユーザＡに薦められる。これは、前述したように、ユーザＡによって所定回数以上（例えば３回以上）、対戦相手として選択されて実際に対戦をした相手を「ライバル」に設定し、この「ライバル」を、ゲームサーバ１がユーザＡに仲間候補として薦めることに該当する。

ここで、ゲームサーバ１側からユーザＡに対して、仲間関係構築のマッチングを積極的に仕掛ける動作例を、図１７のフローチャートに示す。

ユーザＡが、図４に例示するメイン画面内の対戦ボタン８３をクリックして対戦モードを選択したとき（Ｓ２１でＹＥＳ）、ゲームサーバ１の選択手段５３は、所定の選択基準に基づいて、ライバル候補（仲間候補）を選択する（Ｓ２２）。例えば、ユーザＡの直近２０試合の対戦相手の中から、ライバル候補が所定数（例えば５人）選択される。その選択基準としては、前述した様々な基準を採用することができる。

その後、ゲームサーバ１は、選択手段５３が選択したライバル候補の一部または全員を含む対戦相手候補リスト（図６参照）を生成し、ユーザＡの端末装置３の画面に表示させる（Ｓ２３）。これにより、ライバル候補はユーザＡから、対戦相手として選択され易くなる。

ここで、ユーザＡが、対戦相手候補リストの中から、対戦したい相手を１人選択すれば（Ｓ２４でＹＥＳ）、ゲームサーバ１は、図７に例示する対戦プレイ画面をユーザＡの端末装置３に表示させる（Ｓ２５）。このとき、ゲームサーバ１の履歴記憶制御手段５１は、ユーザＡに選択されて対戦相手として対戦プレイ画面に登場した他のユーザに関する情報の履歴を、ユーザＡのユーザＩＤと対応付けて、データベースサーバ２に記憶する（Ｓ２６）。

その後、ゲームサーバ１は、データベースサーバ２に記憶されている前記履歴に基づいて、ユーザＡによって同一のユーザ（例えばユーザＢ）が３回以上、対戦相手として選択されたか否かを判断する（Ｓ２７）。この場合、現在から遡る所定期間（例えば１か月）以内に３回以上という時間的な限定を付加してもよい。ここで、同一のユーザＢが３回以上、ユーザＡによって対戦相手として選択された場合（Ｓ２７でＹＥＳ）、ゲームサーバ１は、そのユーザＢを「ライバル」に設定する（Ｓ２８）。

そして、ゲームサーバ１の推薦手段５２は、対戦プレイの開始時、対戦プレイの途中、または対戦プレイの終了時に、「ライバル」に設定されたユーザＢを仲間候補としてユーザＡに薦める（Ｓ２９）。例えば、図８に例示するように、架空のキャラクタ１６６がユーザＡに対して「ライバル」であるユーザＢと仲間になってはどうかと話かけるような演出を行う。ここでユーザＡがその演出に応えて仲間申請ボタン１６９を押せば、ユーザＢに対して簡単に仲間申請できる。

このフローチャートの動作例では、ユーザＡが強い関心を持つと思われる他のユーザＢ（すなわち、候補リストの中からユーザＡによって選択されて実際にユーザＡと直接的にゲーム内で所定回数以上の接点を持った者）のみを仲間候補として薦めるので、ユーザＡが薦められた仲間候補に対して仲間申請する可能性を高めることができる。これにより、仲間構築の促進を図ることができる。

また、ゲームサーバ１の推薦手段５２は、ユーザＡに「ライバル」である他のユーザＢを仲間候補として薦めた場合、「ライバル」側の他のユーザＢにも並行してユーザＡを仲間候補として薦めることが好ましい（Ｓ３０）。例えば、推薦手段５２は、ユーザＢの端末装置３がゲームサーバ１にアクセスしたときに、図１８に例示する画面演出を発生させる。すなわち、ユーザＢのゲーム画面内にサブウインドウ１６５が表示され、架空のキャラクタ１６６がユーザＢに対してユーザＡと仲間になってはどうかと話かけるような演出を行う。図１８では、テキスト表示領域１６７に、「Ａさんはあなたと３回対戦しましたので、あなたとＡさんは、良きライバルと認定されました。ライバルのＡさんと仲間になってはどうですか？」というメッセージが表示される例を示している。

また、このとき、ゲームサーバ１が仲間候補として推薦するユーザＡに関する情報表示領域１６８および仲間申請ボタン１６９も併せて表示される。情報表示領域１６８には、例えばユーザＡの写真またはアバター、名前、レベル、総コスト、トータルの勝敗、ユーザＢとの対戦の勝敗等が表示される。ここで、ユーザＢが仲間申請ボタン１６９を押せば、ゲームサーバ１から薦められたユーザＡに対して仲間申請を行うことができる。なお、ユーザＢが、薦められたユーザＡに対して仲間申請したくない場合、閉じるボタン１７０を押せば、サブウインドウ１６５が閉じられる。

このように、ゲームサーバ１側からユーザＡおよびユーザＢの双方に対して、仲間関係構築のマッチングを積極的に仕掛けることが好ましい。これにより、例えばユーザＢの方から先にユーザＡに対して仲間申請が届くこともあるが、その場合、ユーザＡにとって、自分のゲーム画面に何度も登場した他のユーザＢについては、関心を引く存在になっていると考えられるので、その仲間申請を承認する可能性は通常よりも高い。よって、仲間関係をさらに構築され易くすることができる。

〔ゲームシステムの他の構成例〕
前述の各実施の形態では、ゲーム実行プログラムがゲームサーバ１側に実装されており、各ユーザの端末装置３における入力操作に応じて、ゲームサーバ１がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置３へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明した。これはいわゆるクライアントサーバ型のゲームシステムであり、サーバ（ゲームサーバ１およびデータベースサーバ２）によってゲーム管理装置を構成する例である。この構成は、前述のように、ブラウザゲーム、ソーシャルゲーム、クラウドゲーミング等のサービスをユーザに提供するのに適した構成であるが、ゲーム管理装置の構成はこれに限定されない。

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

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

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

例えば、図１１ではゲームサーバ１が、履歴記憶制御手段５１および推薦手段５２を備えていたが、図１９に例示するように、各手段の機能をサーバおよび端末装置の何れかに持たせることが可能である。ここで、図１９に示すサーバのハード構成は、図２に示したゲームサーバ１と同様であり、端末装置のハード構成は、図３に示した端末装置３と同様である。図１９には、サーバ１０１に推薦手段５２を設けるとともに、端末装置３０１に履歴記憶制御手段５１を設ける構成例を示している。なお、図１９はゲームシステムの構成の一例であり、他の構成も可能である。

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

また、前述の選択手段５３、相手管理手段５４についても、サーバ側だけではなく、端末装置（ゲーム端末）側に設けることもできる。

〔その他の実施の形態〕
前述の実施の形態においては、ユーザＡの対戦相手候補がリストアップされ、その中からユーザＡが任意の対戦相手を選択することができるゲームについて説明したが、次のようなゲームにも適用できる。すなわち、ユーザＡが対戦を行う場合、対戦相手候補の提示なしに、ゲーム管理装置が自動的にユーザＡの対戦相手を決定する。この場合も、ユーザＡの対戦相手として、同一の他のユーザＢが所定回数以上登場した場合に、ゲーム管理装置は、当該他のユーザＢを仲間候補としてユーザＡに薦める。また、選択手段５３は、第１のユーザＡと仲間関係にない他のユーザの中から、所定の選択基準に基づいて、仲間候補となり得る第２のユーザＢ（Ｃ、Ｄ…）を選択し、相手管理手段５４は、第２のユーザＢ（Ｃ、Ｄ…）を第１のユーザＡの対戦相手として登場させる頻度を、第２のユーザＢ（Ｃ、Ｄ…）以外の他のユーザよりも高くして仲間申請の導線とする。

また、前述の実施の形態においては、ユーザＡの対戦相手または対戦相手候補として、他のユーザがユーザＡのゲーム画面に登場する場合を中心に説明したが、これに限定されるものではない。他のユーザに関する情報がユーザＡのゲーム画面に登場する態様は、ゲームの種類や内容により様々であり、以下にそのバリエーションを説明する。

ユーザＡが対戦相手と対戦を行う場合、ユーザＡの「助っ人」として他のユーザが対戦に協力することができるゲームでは、他のユーザが「助っ人」または「助っ人」候補として、ユーザＡの画面に登場する機会がある。ここで、ユーザＡの仲間だけではなく、仲間関係にない他のユーザも「助っ人」になれるゲームであれば、ユーザＡと仲間関係にない同一の他のユーザの「助っ人」および／または「助っ人」候補としての画面登場回数が、所定回数以上になった場合に、推薦手段５２は、当該他のユーザを仲間候補としてユーザＡに薦める。以下に、具体例を示す。

対戦時に「助っ人」を呼ぶことができるゲームにおいて、ユーザＡが対戦相手を選択した後に表示される対戦開始画面の一例を、図２１に示す。この対戦開始画面には、相手チーム情報表示領域１７１および自チーム情報表示領域１７２が設けられている。相手チーム情報表示領域１７１には、例えば、対戦相手ユーザのアバター、名前、ゲームレベル、総コスト、対戦成績等が表示される。また、自チーム情報表示領域１７２には、ユーザ自身のアバター、名前、ゲームレベル、総コスト、対戦成績等が表示される。

また、対戦開始画面には、「仲間の助っ人を呼ぶ」ボタン１７３が表示され、任意の仲間（または仲間のキャラクタ）を助っ人として要請できるようになっている。ユーザＡがボタン１７３をクリックすることにより、図示しない助っ人選択画面に遷移し、ユーザＡと仲間関係にある仲間がリストアップされる。ユーザＡは任意の仲間を選択して助っ人に設定することができる。このように、仲間を助っ人に呼べるようにすることにより、仲間との交流を促進できる。

さらに、対戦開始画面には、「仲間以外の助っ人を呼ぶ」ボタン１７４も表示され、仲間関係にない他のユーザ（またはそのキャラクタ）も助っ人として要請できるようになっている。このように、仲間以外のユーザも助っ人に呼べるようにすることにより、仲間作りの切っ掛けを与えることができ、仲間作りを促進できる。ユーザＡがボタン１７４をクリックすることにより、図２２に例示する助っ人選択画面（仲間以外）に遷移する。この助っ人選択画面には、複数の助っ人候補表示領域１７６が設けられており、ユーザＡと仲間関係にない他のユーザの中から、ゲームサーバ１によって選択された「助っ人」候補がリストアップされて表示される。助っ人候補表示領域１７６には、例えば「助っ人」候補のアバター、名前、ゲームレベル、総コスト、対戦成績等が表示される。

また、ゲーム管理装置は、選択手段５３によって所定の選択基準に基づいて選択された、ユーザＡと仲間関係にない同一ユーザＢ（Ｃ、Ｄ…）が「助っ人」候補としてユーザＡの画面に表示される頻度を多くすることで、助けられる側のユーザＡに、その「助っ人」候補に対する好意、関心をもたせ、仲間申請への導線とすることもできる。ここで、「助っ人」候補となる他のユーザ（ユーザＡと仲間関係にない者）の選択基準（条件）は、前述した仲間候補の選択基準（例えば、ゲームへのアクセス頻度、対戦頻度、勝率、仲間数、ゲーム開始日時、年齢、レベル等が、ユーザＡと同一またはその違いが所定範囲内など）を利用できる。

ユーザＡは、リストアップされた「助っ人」候補の中から、「助っ人」を依頼したい相手を選び、決定ボタン１７７を押す。これにより、図２３に例示する対戦開始画面に遷移し、仲間以外の助っ人設定領域１７９には、ユーザに選択された相手（図２３の例ではユーザＢ）が、仲間以外の「助っ人」として設定される。なお、図２３では、仲間の助っ人設定領域１７８にも、仲間の「助っ人」が設定されている例を示している。

図２１または図２３の対戦開始画面において、ユーザＡが対戦開始ボタン１７５を押すことにより、ユーザの端末装置３からは対戦コマンドがゲームサーバ１へ送信され、ゲームサーバ１において対戦処理が実行される。ここで、図２３の画面のように、ユーザＡの仲間および／または仲間以外のユーザが「助っ人」として設定されている場合、当該「助っ人」の所持する選手キャラクタの能力等に応じて、ユーザＡのチームの戦力が、「助っ人」が設定されていない場合よりも向上する。ここで、仲間以外の「助っ人」としてユーザＡの対戦に協力したユーザＢは、ユーザＡとゲーム内で接点を持った他のユーザに該当する。

例えば、仲間以外の「助っ人」として、同一のユーザＢが、ユーザＡによって所定回数（例えば３回）選択された場合、対戦プレイの開始時、対戦プレイの途中、または対戦プレイの終了時に、推薦手段５２が、ユーザＢを仲間候補としてユーザＡに薦める。例えば、図２４に例示するように、架空のキャラクタ１６６がユーザＡに対して、何度も「助っ人」として対戦に協力してくれているユーザＢと仲間になってはどうかと話かけるような演出を行う。図２４では、テキスト表示領域１６７に、「Ｂさんは、３回もあなたのチームの助っ人になってくれました。この機会にＢさんと仲間になってはどうですか？」というメッセージが表示される例を示している。ここでユーザＡがその演出に応えて仲間申請ボタン１６９を押せば、ユーザＢに対して簡単に仲間申請できる。

なお、ユーザＡと仲間関係にない同一の他のユーザＢが、ときには対戦相手になることもあれば、「助っ人」になることもあり得る。よって、ユーザＡと仲間関係にない同一の他のユーザＢが、対戦相手としてユーザＡに選択された回数と、「助っ人」としてユーザＡに選択された回数との合計が、所定回数になった場合に、ゲーム管理装置がユーザＢを仲間候補としてユーザＡに薦めてもよい。

次に、他のバリエーションとして、ゲーム内のコミュニティルーム（複数のユーザが入場できる仮想共有空間）について説明する。ユーザＡが、図４に示すメイン画面のコミュニティ入室ボタン８４をクリックすれば、図示しないルーム選択画面に遷移する。このルーム選択画面には複数のコミュニティルームが表示され、ユーザＡは満室でない任意のルームを選択して入場することができる。野球ゲームであれば、このコミュニティルームを、例えば特定チームのファンが集まる仮想スポーツバーとすることができる。

ユーザＡが、コミュニティルームに入室すれば、図２５に例示するコミュニティルーム内の画面に遷移する。この画面には、同一のルームに入室しているメンバの一覧を表示するためのメンバーボード１８０が設けられている。本実施の形態では、メンバーボード１８０内に１２個のメンバ表示領域１８１が設けられており、そのうちの１つがユーザ自身を表すオブジェクト（写真、アバター等）が表示されるユーザ表示領域１８１ａとなっている。また、各メンバ表示領域１８１には、同一のルームに入室している他のユーザの写真、アバター等が表示される。また、各メンバ表示領域１８１をクリックすれば（または各メンバ表示領域１８１にカーソルを合わせれば）、他のユーザのさらに詳細な情報（名前、ゲームレベル、総コスト、対戦成績等）を見ることもできる。

また、画面には、ユーザのお気に入りチームの現実世界の野球の試合の状況をリアルタイムで表示するリアルタイム情報表示領域１８２が設けられている。このリアルタイム情報表示領域１８２には、スコアボード、現在の打者の情報、現在の投手の情報、出塁状況、ボールカウントなどが表示される。なお、リアルタイム情報表示領域１８２には、ＭＬＢの試合の生放送の動画（例えばストリーミング生放送の動画）が表示されるようにしてもよい。また、画面には、入室しているメンバ同士でのみ書き込みおよび閲覧できるリアルタイム掲示１８３が設けられている。よって、同じチームのファン同士でＭＬＢの試合を見ながら、リアルタイムコミュニケーションを楽しむことができるようになっている。また、ユーザＡは、ルーム内の特定の他のユーザを指定して、チャットを楽しむこともできる。

ここで、ユーザＡがゲーム内のコミュニティルームでたまたま一緒になった他のユーザＢ、Ｃ、Ｄ…を、ユーザＡのゲーム画面に登場した他のユーザとして、履歴記憶制御手段５１がデータベースサーバ２に記憶する。また、ユーザＡが特定の他のユーザを指定して（または他のユーザから指定されて）チャットを行った場合には、ユーザＡとゲーム内で直接的に接点を持った他のユーザとして、履歴記憶制御手段５１がデータベースサーバ２に記憶する。そして、例えばユーザＡがコミュニティルーム内で、同一の他のユーザＢと、所定回数以上一緒になった場合、ゲーム管理装置の推薦手段５２がユーザＢを仲間候補としてユーザＡに薦める。また、同時に、ユーザＡを仲間候補としてユーザＢに薦める。

また、ユーザＡがゲーム内のコミュニティルームで、仲間関係にない他のユーザＢ、Ｃ、Ｄ…とたまたま一緒になったことを切っ掛けとして、ゲーム管理装置の選択手段５３は、そのユーザＢ、Ｃ、Ｄ…を優先的にゲーム内の相手（または相手候補）として選択する。そして、相手管理手段５４が、ユーザＡのゲーム中の画面に登場するユーザＢ、Ｃ、Ｄ…（第２のユーザ）の頻度を通常よりも高くする。例えば、前記「助っ人」候補として、または前記対戦相手候補として、ユーザＡのゲーム中の画面に登場し易くし、仲間申請への導線とする。

このように、ゲーム内のあるモードでユーザＡの画面に登場した（またはユーザＡと交流を持った）他のユーザＢ（Ｃ、Ｄ…）について、ゲーム内の別のモードでユーザＡの相手（または相手候補）として登場する頻度を、その他のユーザよりも高くして仲間申請への導線とすることもできる。

次に、他のバリエーションとして、いわゆるレイドボス戦について説明する。レイドボス戦とは、複数のユーザがパーティ（グループ）を組み、互いに協力しながらボスに立ち向かう協力プレイをいう。例えば、野球ゲームでは、複数のユーザが集まって混合チームを結成し、みんなで協力しながらボスチームと対戦する。また、例えばモンスターゲームでは、複数のユーザが集まってパーティを作り、みんなで協力しながらボスモンスターを討伐する。このようなレイドボス戦で、ゲーム管理装置は、ユーザＡと協力するパーティの中に、他の同一ユーザが含まれる頻度を多くして、互いの関心を持たせ、仲間申請への導線とする。ここで、ユーザＡとの協力頻度を高くする他のユーザ（ユーザＡと仲間関係にない者）の選択基準（条件）は、前述した仲間候補の選択基準と同様の基準を採用できる。例えば、現在から遡る１か月以内のレイドボス戦でユーザＡと一緒に協力プレイを行った他のユーザの中から、ゲームへのアクセス頻度、仲間数、ゲーム開始日時、年齢、レベル等が、ユーザＡと同一またはその違いが所定範囲内などとする選択基準を適用することができる。

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

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

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

１ ゲームサーバ（ゲーム管理装置）
２ データベースサーバ（ゲーム管理装置）
３ 端末装置
４ ネットワーク
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 補助記憶装置
５１ 履歴記憶制御手段
５２ 推薦手段
５３ 選択手段
５４ 相手管理手段
１０１、１０２ サーバ（ゲーム管理装置、ゲームシステム）
３０１、３０２ 端末装置（ゲーム管理装置、ゲームシステム）

Claims (8)

1. ユーザ同士が仲間関係を構築することができるゲームを管理するゲーム管理装置であって、
   ユーザのゲーム画面に登場した他のユーザに関する情報の履歴を記憶装置に記憶する履歴記憶制御手段と、
   前記履歴記憶制御手段によって記憶された前記履歴に基づいて、ユーザのゲーム画面に登場した、当該ユーザと仲間関係にない同一の他のユーザに関する情報が所定回数以上になったと判断した場合に、当該他のユーザを仲間候補として前記ユーザに薦める推薦手段と、を備えているゲーム管理装置。
2. 第１のユーザと仲間関係にない他のユーザの中から、所定の選択基準に基づいて、仲間候補となり得る第２のユーザを選択する選択手段と、
   前記選択手段によって選択された第２のユーザに関する情報を、第１のユーザのゲームプレイの相手または相手候補として、第１のユーザのゲーム中の画面に登場させる頻度を、第２のユーザ以外の他のユーザに関する情報よりも高くする相手管理手段と、をさらに備えている請求項１に記載のゲーム管理装置。
3. 前記履歴記憶制御手段は、ユーザのゲーム画面に登場した他のユーザに関する情報のうち、ユーザとゲーム内で接点を持った他のユーザに関する情報の履歴を記憶装置に記憶し、
   前記選択手段は、第１のユーザと仲間関係にないユーザであって、過去に第１のユーザとゲーム内で接点を持ったことのある他のユーザを、接点を持ったことのない他のユーザよりも優先的に前記第２のユーザとして選択する請求項２に記載のゲーム管理装置。
4. 前記推薦手段は、ユーザとゲーム内で所定回数以上接点を持ってユーザのゲーム画面に登場した他のユーザを、当該ユーザに仲間候補として薦める請求項３に記載のゲーム管理装置。
5. 前記推薦手段は、ユーザに仲間候補として薦めた他のユーザに対して、当該ユーザを仲間候補として薦める請求項１ないし４の何れか１項に記載のゲーム管理装置。
6. サーバと、当該サーバとの間で通信を行う端末装置と、を含むゲームシステムであって、
   ユーザのゲーム画面に登場した他のユーザに関する情報の履歴を記憶装置に記憶する履歴記憶制御手段、
   前記履歴記憶制御手段によって記憶された前記履歴に基づいて、ユーザのゲーム画面に登場した、当該ユーザと仲間関係にない同一の他のユーザに関する情報が所定回数以上になったと判断した場合に、当該他のユーザを仲間候補として前記ユーザに薦める推薦手段、を前記サーバ又は前記端末装置のいずれか一方が備えるゲームシステム。
7. ユーザ同士が仲間関係を構築することができるゲームの管理を行うコンピュータにおけるゲーム管理方法であって、
   コンピュータが、ユーザのゲーム画面に登場した他のユーザに関する情報の履歴を記憶装置に記憶する履歴記憶制御ステップと、
   コンピュータが、前記履歴記憶制御ステップによって記憶装置に記憶された前記履歴に基づいて、ユーザのゲーム画面に登場した、当該ユーザと仲間関係にない同一の他のユーザに関する情報が所定回数以上になったと判断した場合に、当該他のユーザを仲間候補として前記ユーザに薦める推薦ステップと、を含むゲーム管理方法。
8. コンピュータを、ユーザ同士が仲間関係を構築することができるゲームを管理するゲーム管理装置として動作させるためのプログラムであって、
   前記コンピュータを、
   ユーザのゲーム画面に登場した他のユーザに関する情報の履歴を記憶装置に記憶する履歴記憶制御手段、
   前記歴記憶制御手段によって記憶された前記履歴に基づいて、ユーザのゲーム画面に登場した、当該ユーザと仲間関係にない同一の他のユーザに関する情報が所定回数以上になったと判断した場合に、当該他のユーザを仲間候補として前記ユーザに薦める推薦手段、
   として機能させるためのプログラム。
   
   

Images