各プレイヤの端末装置と通信し、プレイヤ同士が仲間関係を構築することができるゲームの仲間管理を行うゲーム管理装置であって、仲間関係成立中の2人のプレイヤを関係付けた仲間情報を記憶するとともに、当該2人の仲間関係が解除された後も、当該2人のプレイヤを関係付けた過去の仲間情報を保持する仲間情報記憶手段と、プレイヤが操作する端末装置からの要求に応じて、前記仲間情報記憶手段に記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する仲間履歴送信手段と、前記仲間履歴送信手段が送信した情報を受信して前記プレイヤの過去の仲間プレイヤを表示している前記端末装置にて当該過去の仲間プレイヤを選択する操作が行われた場合に、当該操作の情報を前記端末装置から受信して当該プレイヤから当該過去の仲間プレイヤへの仲間関係復活の申請処理を実行する仲間復活申請手段と、を備えるゲーム管理装置。前記仲間情報記憶手段は、仲間関係にある2人のプレイヤの一方が仲間関係を自主的に解除した場合、当該2人のプレイヤのうち仲間関係を自主的に解除した側のプレイヤと、相手から仲間関係を自主的に解除された側のプレイヤと、を区別して記憶しており、前記仲間履歴送信手段は、プレイヤが操作する端末装置からの要求に応じて、前記仲間情報記憶手段に記憶されている当該プレイヤの過去の仲間情報のうち当該プレイヤが仲間関係を自主的に解除した場合の情報を読み出し、当該プレイヤが仲間関係を自主的に解除した過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する請求項1に記載のゲーム管理装置。仲間申請をしたプレイヤおよび当該申請を承認したプレイヤの2人のプレイヤ間で仲間関係が成立したときに、少なくとも承認した側のプレイヤに対して仲間成立ポイントを付与する仲間成立ポイント付与手段をさらに備え、前記仲間成立ポイント付与手段は、前記仲間復活申請手段が実行した前記仲間関係復活の申請処理による仲間申請を承認した前記過去の仲間プレイヤに対して付与する前記仲間成立ポイントを、前記仲間関係復活の申請処理によらない通常の仲間申請を承認したプレイヤに対して付与する前記仲間成立ポイントよりも高くする請求項1または2に記載のゲーム管理装置。前記仲間復活申請手段が実行した前記仲間関係復活の申請処理による仲間申請を前記プレイヤの過去の仲間プレイヤが承認して当該2人のプレイヤ間で仲間関係が復活した場合、当該2人のプレイヤの仲間関係の復活時間の情報を記憶する復活時間記憶手段と、前記復活時間記憶手段に記憶されている前記2人のプレイヤの復活時間から所定期間が経過するまでは、当該2人のプレイヤ間での仲間関係の再度の復活を許可しない再復活制限手段と、をさらに備えている請求項3に記載のゲーム管理装置。前記仲間復活申請手段が実行した前記仲間関係復活の申請処理による仲間申請を前記プレイヤの過去の仲間プレイヤが承認して当該2人のプレイヤ間で仲間関係が復活した場合、当該2人のプレイヤの仲間関係の復活時間の情報を記憶する復活時間記憶手段をさらに備え、前記仲間履歴送信手段は、前記復活時間記憶手段に記憶されている前記2人のプレイヤの復活時間から所定期間が経過するまでは、当該2人のプレイヤの仲間関係が再度解除された場合であっても、当該2人のプレイヤのうちの一方のプレイヤが操作する端末装置からの要求に応じて過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信するときに、送信する情報の中に他方のプレイヤの情報を含めない請求項3に記載のゲーム管理装置。仲間関係が成立している2人のプレイヤに対して、プレイヤ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段と、仲間関係が成立している2人のプレイヤに対して設定された前記仲間期間の終了により、当該2人のプレイヤの仲間関係を自動的に解除する仲間関係解除手段と、をさらに備える請求項1に記載のゲーム管理装置。各プレイヤの端末装置と通信し、プレイヤ同士が仲間関係を構築することができるゲームの仲間管理を行うゲーム管理装置におけるゲーム管理方法であって、前記ゲーム管理装置が、仲間関係成立中の2人のプレイヤを関係付けた仲間情報を記憶するとともに、当該2人の仲間関係が解除された後も、当該2人のプレイヤを関係付けた過去の仲間情報を保持する仲間情報記憶ステップと、前記ゲーム管理装置が、プレイヤが操作する端末装置からの要求に応じて、前記仲間情報記憶ステップに記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する仲間履歴送信ステップと、前記仲間履歴送信ステップが送信した情報を受信して前記プレイヤの過去の仲間プレイヤを表示している前記端末装置にて当該過去の仲間プレイヤを選択する操作が行われた場合に、前記ゲーム管理装置が、当該操作の情報を前記端末装置から受信して当該プレイヤから当該過去の仲間プレイヤへの仲間関係復活の申請処理を実行する仲間復活申請ステップと、を備えるゲーム管理方法。コンピュータを請求項1ないし6の何れか1項に記載のゲーム管理装置として動作させるためのプログラムであって、前記コンピュータを前記ゲーム管理装置が備えている各手段として機能させるためのプログラム。ところで、プレイヤ間の仲間関係は、何れか一方のプレイヤが仲間の解除操作を行うことにより、解消することができるようになっている。そして、従来のゲームシステムにおいては、一旦解除された仲間関係を再構築するためのシステムはなかった。従来のゲームシステムにおいて、プレイヤが過去の仲間プレイヤと、再度、仲間関係を構築するには、仲間候補として過去の仲間プレイヤを見つけ出して仲間申請をする必要がある。しかし、プレイヤが過去の仲間プレイヤを見つけ出すことは、次に示すように決して容易ではない。すなわち、通常、プレイヤが仲間申請を行う相手は、ゲームサーバから提示される仲間候補リストの中から見つけて選択するのであるが、ゲームサーバは仲間候補をゲームサービス登録者の中からランダムに抽出している。よって、多数の例えば数万人のゲームサービス登録者の中から過去の仲間プレイヤが仲間候補として抽出される確率は決して高くない。このように、従来では、一度、仲間関係が解除されてしまえば、過去の仲間プレイヤと仲間関係を再構築することは困難であった。本発明は、上記の問題に鑑みてなされたものであり、その目的は、過去の仲間プレイヤと仲間関係を再構築するための機会が持てるゲーム環境をプレイヤに提供するゲーム管理装置、ゲーム管理方法及びプログラムを実現することである。1本発明の一局面によるゲーム管理装置は、各プレイヤの端末装置と通信し、プレイヤ同士が仲間関係を構築することができるゲームの仲間管理を行うゲーム管理装置であって、仲間関係成立中の2人のプレイヤを関係付けた仲間情報を記憶するとともに、当該2人の仲間関係が解除された後も、当該2人のプレイヤを関係付けた過去の仲間情報を保持する仲間情報記憶手段と、プレイヤが操作する端末装置からの要求に応じて、前記仲間情報記憶手段に記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する仲間履歴送信手段と、前記仲間履歴送信手段が送信した情報を受信して前記プレイヤの過去の仲間プレイヤを表示している前記端末装置にて当該過去の仲間プレイヤを選択する操作が行われた場合に、当該操作の情報を前記端末装置から受信して当該プレイヤから当該過去の仲間プレイヤへの仲間関係復活の申請処理を実行する仲間復活申請手段と、を備える構成である。この構成のゲーム管理装置は、各プレイヤの端末装置と通信を行うことができる、例えばサーバなどの情報処理装置により構成することができる。そして、本ゲーム管理装置は、プレイヤ同士が仲間関係を構築することができるゲーム、例えばプレイヤ同士が仲間になって交流を楽しむことができるソーシャルゲーム等のゲームの仲間管理を行う。ここで、仲間関係とは、ゲーム内で構築されるプレイヤ同士の仮想的な関係の総称であり、知人、友人、友達、クラスメイト、相棒、親類、家族、兄弟、姉妹、会社や組織の同僚などの様々なゲーム内の関係を含む。また、本ゲーム管理装置は、仲間関係成立中の2人のプレイヤを関係付けた仲間情報を記憶する仲間情報記憶手段を備えている。この仲間情報記憶手段は、2人の仲間関係が解除された後も、当該2人のプレイヤを関係付けた過去の仲間情報を保持する。また、本ゲーム管理装置は、仲間履歴送信手段を備えている。この仲間履歴送信手段は、プレイヤが操作する端末装置からの要求に応じて、仲間情報記憶手段に記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する。この仲間履歴送信手段が送信した情報を受信したプレイヤの端末装置では、当該プレイヤの過去の仲間プレイヤを表示することができる。よって、プレイヤは、自分の過去の仲間履歴を、端末装置の表示画面上で容易に確認することができる。すなわち、プレイヤは、自分の過去の仲間プレイヤを確実且つ容易に特定できる。そして、プレイヤにより、過去の仲間プレイヤを表示している端末装置にて、過去の仲間プレイヤを選択する操作が行われた場合には、仲間復活申請手段が当該操作の情報を受信して、当該プレイヤから当該過去の仲間プレイヤへの仲間関係復活の申請処理を実行する。すなわち、プレイヤは、端末装置に表示されている過去の仲間プレイヤを確認して、仲間関係を復活させたい所望の相手を選択する操作をすることで、その相手に対する仲間関係復活の申請を容易に行うことができる。なお、プレイヤから仲間関係復活の申請を受けた相手当該プレイヤの過去の仲間プレイヤ、がそれを承認すれば、両者の仲間関係が復活することは言うまでもない。以上のように、本構成により、プレイヤの端末装置に過去の仲間プレイヤを表示させて所望の相手に対して簡単に仲間関係復活の申請を行えるようにするという従来にはない斬新な機能をプレイヤに提供できる。これにより、過去の仲間プレイヤと仲間関係を再構築するための機会が持てるゲーム環境をプレイヤに提供できる。よって、例えば、従来ではなし得なかった下記a~cのようなことも可能になる。aプレイヤが、仲間であった相手との仲間関係を誤操作等により誤って解除してしまった場合、その後、同じ相手と仲間関係を再構築する機会が得られる。b何らかの理由例えば、海外出張や受験に専念等でプレイヤが一時的に暫くゲームから離れる必要が生じた場合、その間、仲間プレイヤとの仲間関係を解消し、その後、ゲームを再開するときに、過去の仲間プレイヤに仲間関係復活の申請を行う。c各プレイヤが他のプレイヤと仲間関係を構築することができる仲間数に上限が設定されているゲームにおいて、次のようなことが可能になる。すなわち、仲間数が上限に達しているプレイヤが、新しい他のプレイヤYと仲間になるために、仲間プレイヤXとの関係を一旦解除する。その後、プレイヤYと思うような交流ができなかったような場合には、プレイヤYとの関係を解除した上で、プレイヤXに仲間関係復活の申請を行う。このように、限られた仲間枠を有効に使った新たなゲームの楽しみ方ができる。2上記の構成において、前記仲間情報記憶手段は、仲間関係にある2人のプレイヤの一方が仲間関係を自主的に解除した場合、当該2人のプレイヤのうち仲間関係を自主的に解除した側のプレイヤと、相手から仲間関係を自主的に解除された側のプレイヤと、を区別して記憶しており、前記仲間履歴送信手段は、プレイヤが操作する端末装置からの要求に応じて、前記仲間情報記憶手段に記憶されている当該プレイヤの過去の仲間情報のうち当該プレイヤが仲間関係を自主的に解除した場合の情報を読み出し、当該プレイヤが仲間関係を自主的に解除した過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信することが好ましい。この構成によれば、仲間情報記憶手段が2人のプレイヤを関係付けた過去の仲間情報を記憶するにあたり、仲間関係を自主的に解除した側と解除された側とを区別して記憶している。そして、仲間履歴送信手段は、プレイヤが操作する端末装置からの要求に応じて、当該プレイヤが仲間関係を自主的に解除した過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する。よって、仲間履歴送信手段が送信した情報を受信したプレイヤの端末装置には、当該プレイヤが自ら仲間関係を解除した過去の仲間プレイヤのみが表示され、当該プレイヤが相手から仲間関係を解除された場合の相手情報は表示されないようにすることができる。本構成により、仲間関係を解除された側のプレイヤが、解除した側のプレイヤに対して、仲間復活申請をすることがなくなる。これにより、仲間関係を自主的に解除した側のプレイヤが、折角解除した仲間プレイヤから、後日、望まないかたちで仲間関係復活の申請を受けるといった事態を効果的に回避できる。また、相手から仲間関係を解除された側のプレイヤにとっても、自分を解除した相手に対して復活申請をしようと思わないことが多いと考えられる。よって、プレイヤにとっては、自分を解除した相手が省かれた状態で過去の仲間プレイヤが表示されることにより、所望の相手を見つけ易くなるという効果も期待できる。3上記の1または2の構成において、ゲーム管理装置は、仲間申請をしたプレイヤおよび当該申請を承認したプレイヤの2人のプレイヤ間で仲間関係が成立したときに、少なくとも承認した側のプレイヤに対して仲間成立ポイントを付与する仲間成立ポイント付与手段をさらに備えていることが好ましい。そして、前記仲間成立ポイント付与手段は、前記仲間復活申請手段が実行した前記仲間関係復活の申請処理による仲間申請を承認した前記過去の仲間プレイヤに対して付与する前記仲間成立ポイントを、前記仲間関係復活の申請処理によらない通常の仲間申請を承認したプレイヤに対して付与する前記仲間成立ポイントよりも高くすることが好ましい。この構成によれば、仲間申請側および承認側の両プレイヤ間で仲間関係が成立したときに、仲間成立ポイント付与手段が、少なくとも承認側のプレイヤに対して仲間成立ポイントを付与する。これは、仲間申請側および承認側の両方のプレイヤにそれぞれ仲間成立ポイントを付与する形態と、承認側のプレイヤのみに仲間成立ポイントを付与する形態とを含む。そして、仲間成立ポイント付与手段は、仲間関係復活の申請処理による仲間申請を承認した過去の仲間プレイヤに対して付与するポイントを、通常の仲間申請を承認したプレイヤに対して付与するポイントよりも高くする。これにより、仲間関係復活の申請を受けたプレイヤの承認を促進し、仲間関係が復活され易いようにすることで、仲間関係を復活させる機能の実効性を高めることができる。4上記の3の構成において、ゲーム管理装置は、前記仲間復活申請手段が実行した前記仲間関係復活の申請処理による仲間申請を前記プレイヤの過去の仲間プレイヤが承認して当該2人のプレイヤ間で仲間関係が復活した場合、当該2人のプレイヤの仲間関係の復活時間の情報を記憶する復活時間記憶手段と、前記復活時間記憶手段に記憶されている前記2人のプレイヤの復活時間から所定期間が経過するまでは、当該2人のプレイヤ間での仲間関係の再度の復活を許可しない再復活制限手段と、をさらに備えていることが好ましい。前述のように、仲間関係復活の申請を承認した方が、通常の仲間申請を承認するより多くのポイントが得られるようにした場合、仲間同士でポイントの獲得だけを狙って仲間関係の解消と復活とを短期間で繰り返すという不適正な事態が生じる可能性がある。本構成は、このような事態を回避するため、復活時間記憶手段がプレイヤ間で仲間関係が復活したときの復活時間を記憶しておき、再復活制限手段が、復活時間から所定期間が経過するまでは仲間関係の再度の復活を許可しないように構成している。ここで、復活時間記憶手段は復活時間として、年、月、日、時、分、秒等の時間情報を記憶するが、ここで記憶する時間の単位は任意に設定できる。また、仲間関係の復活後に再復活が禁止される期間である前記の所定期間としては、任意の期間を設定可能である。例えば、所定期間を一定の期間例えば3か月等としてもよいし、仲間関係の復活回数に応じて所定期間を変動させる復活回数が多いほど所定期間を長く設定するようにしてもよい。本構成により、2人のプレイヤが仲間関係の解除と復活とを繰り返すことによる不適正なポイント狙いを画策しても、一度仲間関係を復活させた後は、所定期間例えば3か月が経過するまで再度の復活ができなくなる。よって、仲間同士でポイントの獲得だけを狙って仲間関係の解消と復活とを短期間で繰り返すという不適正なプレイヤの行動を、効果的に抑制することができる。5上記の3の構成において、ゲーム管理装置は、前記仲間復活申請手段が実行した前記仲間関係復活の申請処理による仲間申請を前記プレイヤの過去の仲間プレイヤが承認して当該2人のプレイヤ間で仲間関係が復活した場合、当該2人のプレイヤの仲間関係の復活時間の情報を記憶する復活時間記憶手段をさらに備えていることが好ましい。そして、前記仲間履歴送信手段は、前記復活時間記憶手段に記憶されている前記2人のプレイヤの復活時間から所定期間が経過するまでは、当該2人のプレイヤの仲間関係が再度解除された場合であっても、当該2人のプレイヤのうちの一方のプレイヤが操作する端末装置からの要求に応じて過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信するときに、送信する情報の中に他方のプレイヤの情報を含めないことが好ましい。この構成によれば、復活時間記憶手段が2人のプレイヤ間で仲間関係が復活したときの復活時間を記憶しておき、仲間履歴送信手段が、復活時間から所定期間が経過するまでは、当該2人のプレイヤのうちの一方の端末装置へ送信する、過去の仲間プレイヤを表示させるための情報中に、他方のプレイヤの情報を含めないように構成している。これにより、2人のプレイヤが仲間関係の解消と復活とを繰り返すことによる不適正なポイント狙いを画策しても、一度仲間関係を復活させた後は、所定期間例えば3か月が経過するまで、お互い相手のプレイヤが過去の仲間プレイヤとして端末装置に表示されないので、仲間関係復活の申請ができなくなる。よって、仲間同士でポイントの獲得だけを狙って仲間関係の解消と復活とを短期間で繰り返すという不適正なプレイヤの行動を、効果的に抑制することができる。6上記の1の構成において、ゲーム管理装置は、仲間関係が成立している2人のプレイヤに対して、プレイヤ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段と、仲間関係が成立している2人のプレイヤに対して設定された前記仲間期間の終了により、当該2人のプレイヤの仲間関係を自動的に解除する仲間関係解除手段と、をさらに備えていることが好ましい。この構成によれば、次に説明するように、自分好みの仲間グループを構築し易い環境をプレイヤに提供することができる。すなわち、比較的高いレベルのプレイヤは、自分と同レベルまたは自分より高いレベルの他のプレイヤと仲間になることを希望する傾向にある。但し、プレイヤは、自分よりも低いレベルの他のプレイヤから仲間申請を受けた場合に、無碍にその申請を断りづらいこともあり、その申請を承認して仲間になるケースがある。しかし、高いレベルのプレイヤにとって、自分よりも低いレベルの仲間が多くなると、ゲームにおける協力対戦等について不公平感が生じてしまうこともある。その理由は、高いレベルのプレイヤにとっては、他のプレイヤに対して協力対戦等における貢献度が大きいのに対して、同様の貢献を低いレベルのプレイヤからは受けられないためである。具体的には、ソーシャルゲームにおいては、プレイヤが他のプレイヤと対戦する場合に、自分の仲間に協力を求めることができる協力対戦と呼称されることがある。そして協力を求める対象の仲間のレベルが高いほど、対戦が有利になるのである。逆に、仲間のレベルが低いと、有利になる度合いも低いものとなる。従って、概ね、レベルの高いプレイヤは、レベルの低いプレイヤから協力を求められることが多くなり、他のプレイヤに貢献するケースが多くなる一方で、仲間内に自分よりレベルの高いプレイヤがいない場合には、同様のメリットを自分は享受できないという不満が生じることになる。このため、高いレベルのプレイヤとしては、できれば、自分よりレベルの低い下位のプレイヤとの仲間関係を解消して、自分の好みの仲間のグループ構成としたいという希望を持つことがある。また、プレイヤより下位レベルの仲間プレイヤであっても、ゲーム内で楽しく交流ができるような仲間プレイヤであればよいが、仲間になってからあまり交流もなく、一緒にゲームを楽しめないような下位レベルの仲間プレイヤに対しては、仲間関係の解消をプレイヤが望むことが多い。しかし、そのためには、プレイヤが今まで仲間であった他のプレイヤ自分より低いレベルの仲間との関係を切る操作が必要であるが、心理的に行い難いと思うプレイヤも多い。そこで、本ゲーム管理装置は、仲間関係が成立している2人のプレイヤに対して、プレイヤ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段を備えている。ここで、仲間期間設定手段が設定する仲間期間の長さとしては、例えば1週間、10日、2週間、1ヶ月など、任意の期間長さに設定可能である。また、仲間期間の長さは固定であってもよいし、例えば設定時にランダムに期間長さを変えてもよいし、プレイヤ間のレベル関係に応じて適切な期間長さを決定するようにしてもよい。また、仲間期間設定手段が仲間期間を設定するタイミングについても、任意に定めることができる。例えば、仲間期間の設定タイミングは、仲間関係の成立時であってもよいし、仲間関係が成立してから一定期間例えば1週間経過後であってもよいし、例えば2人のプレイヤ間で所定期間、交流が行われなかった状態が発生したときであってもよい。そして、仲間関係解除手段は、仲間関係が成立している2人のプレイヤに対して設定された仲間期間の終了により、当該2人のプレイヤの仲間関係を自動的に解除するようになっている。よって、プレイヤは、心理的にも行い難い仲間解除の操作を行うことなく、仲間期間の終了により仲間関係の解除が可能となる。したがって、プレイヤは、例えば仲間になってから殆ど交流等もなく一緒にゲームを楽しめないような下位レベルの仲間に対しては、仲間期間の終了により仲間関係を断ち、改めて、自分の好みの新たな仲間を探すことができる。そして、プレイヤが仲間関係を継続したいと思うような相手であれば、仲間期間終了後に改めて同じ相手に、上述の仲間関係復活の申請を行えばよい。このように、プレイヤは、一緒にゲームを楽しめなかった下位レベルの仲間とは、仲間期間の終了により仲間関係を終え、仲間関係復活の申請をしたりすることはないと考えられる。その一方、プレイヤが望むような相手例えば、上位レベルのプレイヤや下位レベルであっても交流等により一緒にゲームを楽しめるようなプレイヤとは、仲間関係を継続するために、仲間関係復活の申請をすることが考えられる。よって、本構成により、仲間関係成立による仲間期間設定と、仲間期間終了による仲間関係の自動解除と、必要に応じた仲間関係復活の申請とを繰り返しながら、プレイヤの好むような仲間グループの構成に収束されていく環境が整えられるのである。本構成のように、プレイヤによる意図的な解除ではなく、2人のプレイヤに設定された仲間期間の終了により仲間関係が自動解除される場合、仲間関係の解除が多くなる分、仲間関係を復活させたいと考える機会もまた多くなるため、仲間復活申請を簡単な操作で容易に行うことができる上記1の構成が好適である。7本発明の他の一局面によるゲーム管理方法は、各プレイヤの端末装置と通信し、プレイヤ同士が仲間関係を構築することができるゲームの仲間管理を行うゲーム管理装置におけるゲーム管理方法であって、前記ゲーム管理装置が、仲間関係成立中の2人のプレイヤを関係付けた仲間情報を記憶するとともに、当該2人の仲間関係が解除された後も、当該2人のプレイヤを関係付けた過去の仲間情報を保持する仲間情報記憶ステップと、前記ゲーム管理装置が、プレイヤが操作する端末装置からの要求に応じて、前記仲間情報記憶ステップに記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する仲間履歴送信ステップと、前記仲間履歴送信ステップが送信した情報を受信して前記プレイヤの過去の仲間プレイヤを表示している前記端末装置にて当該過去の仲間プレイヤを選択する操作が行われた場合に、前記ゲーム管理装置が、当該操作の情報を前記端末装置から受信して当該プレイヤから当該過去の仲間プレイヤへの仲間関係復活の申請処理を実行する仲間復活申請ステップと、を備える構成である。8本発明の更に他の一局面によるプログラムは、コンピュータを上記の1ないし6の何れかの構成のゲーム管理装置として動作させるためのプログラムであって、前記コンピュータを前記ゲーム管理装置が備えている各手段として機能させるためのプログラムである。本発明によれば、プレイヤの端末装置に過去の仲間プレイヤを表示させて所望の相手に対して簡単に仲間関係復活の申請を行えるようにするという従来にはない斬新な機能をプレイヤに提供できる。これにより、過去の仲間プレイヤと仲間関係を再構築するための機会が持てるゲーム環境をプレイヤに提供できる。以下、本発明の一実施の形態に係るゲーム管理装置、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。ゲームシステムの概要本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図1に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク4上に設置されたゲームサーバ1と、当該ゲームサーバ1と通信可能に接続されたデータベースサーバ2と、ネットワーク4を介してゲームサーバ1と通信可能に接続できる各プレイヤの端末装置3とによって構成される。本実施の形態のネットワーク4は、インターネットに限定されるものではなく、ゲームサーバ1と各プレイヤの端末装置3との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線電話回線、移動体通信回線等、有線LANLocalAreaNetwork、無線LAN等であってもよく、或いはインターネットとこれらを組み合わせたものであってもよい。このゲームシステムの例において、本発明の一実施の形態に係るゲーム管理装置は、ゲームサーバ1およびデータベースサーバ2から構成される。ゲームサーバ1は、ゲームサービスを受ける各プレイヤの端末装置3からのネットワーク4を介したアクセスを受け付けて、各プレイヤのゲーム情報をデータベースサーバ2記憶装置に蓄積して管理し、各プレイヤにネットワーク4を介したゲームサービスを提供する。本実施の形態では、ゲームサーバ1によるゲームサービスの提供の一形態として、各プレイヤの端末装置3に搭載されたウェブブラウザによってゲームがプレイできる、いわゆるブラウザゲームを提供する例について説明する。このブラウザゲームを提供するサービス形態では、プレイヤの端末装置3にゲーム専用のソフトウェアをダウンロード又はインストールする必要がなく、端末装置3をネットワーク4に接続できる環境であれば、プレイヤはどこでも気軽にゲームサーバ1から提供されるゲームサービスを楽しむことができる。このゲームシステムでは、ブラウザゲーム用のプログラムアプリケーションソフトウェアがゲームサーバ1に実装されており、ゲームサーバ1が、各プレイヤの端末装置3における入力操作に応じてゲーム進行のための演算処理やデータ処理を実行する。そして、ゲームサーバ1は、演算処理等の実行結果に基づいてデータベースサーバ2内の各プレイヤのゲーム情報を更新するとともに、当該実行結果をプレイヤの端末装置3の画面に表示させるためのウェブページ情報ゲーム画面データを各プレイヤの端末装置3に送信する。各プレイヤの端末装置3には、プレイヤーエージェントとしてウェブサイト閲覧機能を有するウェブブラウザが搭載されており、ゲームサーバ1から送信されたウェブページ情報を端末装置3の画面に表示することができるようになっている。この端末装置3としては、例えば、携帯電話端末、PHSPersonalHandyphoneSystem端末、携帯情報端末PDA:PersonalDigitalAssistant、携帯電話と携帯情報端末とを融合させた携帯端末であるスマートフォン、パーソナルコンピュータまたはタブレット型コンピュータなど、ネットワーク4経由でゲームサーバ1に接続してゲームサービスの提供を受けることができる様々な端末が適用できる。また、本実施の形態で提供されるゲームは、プレイヤが、ゲームサービスを受けている他のプレイヤとコミュニケーションをとりながらプレイすることができる、いわゆるソーシャルゲームの要素を有する。例えば、本実施の形態のゲームサーバ1およびデータベースサーバ2をソーシャルネットワーキングサービスSNSのシステムに組み込むことによって、SNSのサービスの一つとしてソーシャルゲームサービスを提供するゲームシステムとすることができる。このようにSNSのプラットフォーム上で動作するゲームシステムによりゲームサービスをプレイヤに提供することもできるが、ゲームサーバ1およびデータベースサーバ2をSNSのシステムに組み込まずに、独立したゲームシステムとして構築してもよい。このゲームシステムにおいて、各プレイヤは、ゲームサービスを受けている1人又は複数の他のプレイヤと仲間という特別な関係を構築できる。あるプレイヤが他のプレイヤと仲間関係を構築するための一形態としては、2人のプレイヤの何れか一方が、他方のプレイヤに対してゲームサーバ1を介して仲間申請を行い、当該仲間申請を受けたプレイヤがゲームサーバ1を介して仲間になることを承認するという、両プレイヤ間においてなされる仲間申請とその承認の操作が挙げられる。2人のプレイヤ間で仲間関係が成立した場合、ゲームサーバ1は当該2人のプレイヤの識別情報プレイヤIDを関係付けた仲間情報をデータベースサーバ2に登録する。そして、ゲームサーバ1は、各プレイヤを中心とする仲間グループに所属する仲間関係にある仲間プレイヤの情報をデータベースサーバ2に記憶して、プレイヤ毎の仲間管理を行う。この仲間申請、その承認およびゲームサーバ1による仲間管理の詳細については後述する。また、各プレイヤは、必要に応じて仲間プレイヤとの仲間関係を解除することができる。そして、本実施の形態のゲームサーバ1は、2人の仲間関係が解除された後も、当該2人のプレイヤを関係付けた過去の仲間情報を、データベースサーバ2に保持するようになっている。また、ゲームサーバ1は、プレイヤが操作する端末装置3からの要求に応じて、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を、当該端末装置3へ送信するようになっている。よって、プレイヤは、自己の端末装置3を操作して、いつでも自分の過去の仲間履歴を、端末装置3の表示画面上で容易に確認することができる。さらに、プレイヤは、端末装置3に表示されている過去の仲間プレイヤを確認して、仲間関係を復活させたい所望の相手を選択する操作を行うことで、その相手に対する仲間関係復活の申請を容易に行うことができるようになっている。これにより、プレイヤは、過去の仲間プレイヤと仲間関係を再構築する機会が与えられることになる。プレイヤから仲間関係復活の申請を受けた相手がそれを承認すれば、両者の仲間関係が復活する。以下に、上記のようにプレイヤに過去の仲間プレイヤとの仲間関係を再構築するための機会を与えることができる、本実施の形態に係るゲーム管理装置ゲームサーバ1等の構成の詳細を説明する。ゲーム管理装置の構成上述のように本実施の形態では、ゲーム管理装置は、ゲームサーバ1およびデータベースサーバ2から構成される。図2にゲームサーバ1のハード構成の一例を示している。同図に示すように、ゲームサーバ1は、主に、CPUCentralProcessingUnit11と、主記憶装置としてのROMReadOnlyMemory12及びRAMRandomAccessMemory13と、補助記憶装置14と、通信制御部15と、入出力制御部16とを備えており、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン17を介して相互に接続されている。なお、バスライン17と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。CPU11は、システムソフトウェアやゲームプログラム等のアプリケーションソフトウェアの命令を解釈して実行し、ゲームサーバ1全体の制御を行う。ROM12は、ゲーム管理装置1の基本的な動作制御に必要なプログラム等を記憶している。RAM13は、各種プログラム及びデータを記憶し、CPU11に対する作業領域を確保する。補助記憶装置14は、ゲームプログラム等のアプリケーションソフトウェアや各種データ等を格納する記憶装置である。補助記憶装置14としては、例えばハードディスクドライブなどを用いることができる。ゲームサーバ1コンピュータをゲーム管理装置として動作させるための本実施の形態のプログラムも、この補助記憶装置14に記憶されており、当該プログラムはゲームサーバ1の起動時に補助記憶装置14からバスライン17を介してRAM13へとロードされ、当該CPU11によって実行される。通信制御部15は、ネットワーク4と接続される通信インタフェース15aを備え、ネットワーク4を介した各プレイヤの端末装置3との間の通信を制御する。また、通信制御部15は、ネットワーク4に接続されている図示しないサーバとの通信も制御するようになっている。例えば、ゲームサーバ1をSNSに組み込んだシステム構成とした場合、ゲームサーバ1の通信制御部15は、SNSサーバとの間の通信を制御する。入出力制御部16は、データベースサーバ2と通信可能に接続されており、CPU11がデータベースサーバ2に対してデータレコードの読み書きを実行するときの入出力制御を行うデータベースインタフェースである。データベースサーバ2は、ゲームサーバ1が管理する各プレイヤのゲーム情報を記憶する領域を有する記憶装置として、例えばRAIDRedundantArraysofInexpensiveDisks構成の大容量ハードディスク装置を具備する。このデータベースサーバ2は、例えば、各プレイヤを一意に識別する識別情報プレイヤIDと対応付けて、各プレイヤの各種ゲーム情報プレイヤ名、レベル、ゲーム内ポイント、所持アイテムなどを記憶するリレーショナルデータベース、オブジェクトデータベース又はオブジェクト関係データベース等として構築することができる。本実施の形態では、ゲーム管理装置がゲームサーバ1およびデータベースサーバ2から構成される例を示すが、これに限定されるものではない。例えば、ゲームサーバ1にデータベースサーバ2の機能を持たせて、ゲーム管理装置をゲームサーバ1のみで構成することもできる。また、ゲームサーバ1の有する各機能を複数のサーバに分散して持たせて、ゲームサーバ1を複数台のサーバとして構成することもできる。例えば、プレイヤが端末装置3を操作してゲームサーバ1へアクセスした場合に、当該プレイヤが正規のプレイヤかどうかを判別する認証機能を有する認証サーバを、ゲームサーバ1のメインサーバとは別に設け、メインサーバと認証サーバとでゲームサーバ1を構成してもよい。他の構成例としては、プレイヤが課金対象のアイテムをゲーム内で購入した場合に課金管理を行う課金管理サーバを、ゲームサーバ1のメインサーバ等とは別に設け、メインサーバ、認証サーバおよび課金管理サーバによりゲームサーバ1を構成してもよい。また、本ゲームサービスを利用するプレイヤ数が数十万人、数百万人、あるいはそれ以上となると、多数のプレイヤの端末装置3からの巨大なアクセスにも耐え得るサーバシステムの構築が求められるため、ネットワーク4上に複数のゲームサーバ1を設けて冗長化多重化を図ることにより、負荷分散型のシステム構成としてもよい。この場合、複数のゲームサーバ1間の負荷を調整するためのロードバランサを設けることが望ましい。次に、本実施の形態に係るゲームサーバ1にアクセスしてゲームサービスの提供を受けるプレイヤの端末装置3の構成を説明する。端末装置の構成プレイヤが操作する端末装置3としては、上述のように携帯電話端末やスマートフォンをはじめとして、ウェブサイト閲覧機能を有する様々な端末を適用できるが、本実施の形態では、携帯電話端末を例示してその構成を説明する。なお、携帯電話端末以外の端末装置3についても、ウェブサイト閲覧機能を用いてゲーム画面を表示したり、ゲームを実行するための入力操作を行うといった、ゲームをプレイする上で必要となる基本的な構成は、携帯電話端末と同様である。ウェブサイト閲覧機能等を有する携帯電話端末は、フィーチャーフォンFeaturephoneやスマートフォンsmartphoneとも呼称され、図3にその構成例を示している。同図に示すように、端末装置3は、主に、CPU31と、主記憶装置としてのROM32及びRAM33と、画像処理部34と、表示部35と、サウンド処理部36と、音声入力部37と、音声出力部38と、補助記憶装置39と、操作入力部40と、通信制御部41とを備えており、構成要素31~34、36および39~41はバスライン42を介して相互に接続されている。なお、バスライン42と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。CPU31は、ウェブブラウザを含む各種プログラムの命令を解釈して実行し、端末装置3全体の制御を行う。ROM32には、端末装置3の基本的な動作制御に必要なプログラム等が記憶されている。また、RAM33には、ROM32または補助記憶装置39からロードされた各種プログラムやデータが記憶され、CPU31に対する作業領域を確保する。HTML等で記述されたゲーム画面データを表示するウェブブラウザは、ROM32または補助記憶装置39に記憶されており、RAM33にロードされてCPU31によって実行される。また、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインソフトウェアを、ウェブブラウザと共にROM32または補助記憶装置39に記憶していてもよい。画像処理部34は、CPU31からの画像表示命令に基づいて表示部35を駆動し、当該表示部35の画面に画像を表示させる。表示部35には、液晶ディスプレイヤ有機LEElectroLuminescenceディスプレイ等の既知の種々の表示装置が適用できる。サウンド処理部36は、音声入力部37から音声が入力されたときにアナログ音声信号をデジタル音声信号に変換するとともに、CPU31からの発音指示に基づいてアナログ音声信号を生成して音声出力部38に出力する。音声入力部37は、端末装置3に内蔵されたマイクロフォンからなり、電話通信する場合や録音を行う場合などに用いられる。音声出力部38は、電話通信時の受話スピーカおよび電話着信音やゲーム実行時の効果音などを出力するスピーカからなる。補助記憶装置39は、各種プログラムやデータ等を格納する記憶装置である。補助記憶装置39としては、携帯電話端末の内部メモリとして、例えばフラッシュメモリドライブ等を用いることができ、また、携帯電話端末の外部メモリとして、例えばメモリカードリーダライタ等を用いることができる。操作入力部40は、プレイヤの操作入力を受け入れて当該操作入力に対応した入力信号を、バスライン42を介してCPU31に出力するものである。操作入力部40の例としては、端末装置3の本体に設けられた方向指示ボタン、決定ボタン、英数文字等入力ボタンなどの物理的ボタンがある。また、表示部35の画面にタッチパネル接触入力式のインタフェースを搭載することによって表示部35をいわゆるタッチスクリーンとして構成している端末装置3の場合、当該タッチパネルも操作入力部40となる。通信制御部41は、通信インタフェース41aを備え、ゲーム操作時等にデータ通信するための通信制御機能および携帯電話端末として音声データを送受信するための通信制御機能等を有している。ここで、データ通信用の通信制御機能には、例えば、無線LAN接続機能、無線LANや携帯電話回線網を介したインターネット接続機能、所定の周波数帯例えば2.4GHzの周波数帯を用いた近距離無線通信機能などが含まれる。通信制御部41は、CPU31からの命令に基づいてゲーム装置1を無線LANやインターネット等に接続するための接続信号を発信するとともに、通信相手側から送信されてきた情報を受信してCPU31へ供給する。なお、端末装置3には、その他にもGPSGlobalPositioningSystem信号受信回路、CCDChargeCoupledDeviceイメージセンサ等の撮像装置カメラ、3軸加速度センサなどが備えられていてもよく、例えば、GPS位置情報などをゲーム内で活用してもよい。上記構成の端末装置3において、ゲームサービスを受けようとするプレイヤは、ウェブブラウザを立ち上げてゲームサーバ1が管理するゲームサイトにアクセスする操作を行う。このアクセスがゲームサーバ1に認証された場合、端末装置3の通信制御部41がゲームサーバ1から送信されてくるHTML等で記述されたゲーム画面データを受信し、CPU31がウェブブラウザを実行してゲーム画面を表示部35に表示させる。ここでプレイヤは、ゲーム画面に表示されている選択可能なボタンオブジェクトやハイパーリンクを、操作入力部40を操作して選択入力する。この選択入力に応じてゲームサーバ1がゲームを進行させ、新たなゲーム画面データを端末装置3に送信する。そして、この新たなゲーム画面が端末装置3の表示部35に表示され、以下、同様に、プレイヤは、表示部35に表示されているゲーム画面で選択可能なボタンオブジェクト等を選択する操作により、ゲームサーバ1が提供するゲームをプレイすることができるようになっている。ゲーム管理装置の機能的構成次に、上記のように構成されたゲーム管理装置ゲームサーバ1およびデータベースサーバ2の主要な機能について説明する。図4は、ゲーム管理装置の主要機能ブロック図である。ゲーム管理装置は、主に、ゲーム情報管理手段51、ゲーム進行手段52、認証手段53、仲間管理手段54、交流手段55、仲間履歴送信手段101および仲間復活申請手段102を備えている。これらの各手段は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。ゲーム情報管理手段51は、各プレイヤのゲーム情報をデータベースサーバ2に蓄積して管理する。ゲーム情報管理手段51で管理されるゲーム情報の項目は、本ゲームサーバ1がプレイヤに提供するゲームサービスの内容によって異なる。本ゲームサーバ1によって提供されるゲームの例としては、野球、サッカー、ゴルフなどの各種スポーツを題材としたスポーツゲーム、戦闘を題材とした戦闘ゲーム、音楽シミュレーションゲーム、その他種々のロールプレイングゲーム育成ゲームシミュレーションゲームといったように、ゲーム形式ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、ゲームサーバ1がゲームサービスとして野球ゲームを提供する場合について、以下に説明する。本実施の形態では、プレイヤがゲーム内において選手キャラクタを所有し、当該選手キャラクタを用いてゲーム内で他のプレイヤと試合対戦を行うことができる野球ゲームを例に挙げる。プレイヤが所有する選手キャラクタは、当該選手キャラクタの形態を端末装置3の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手カードとしてゲームサーバ1で管理されるとともに、プレイヤの端末装置3の画面に表示される。図13には、プレイヤの端末装置3の画面に表示される選手カード71を例示しており、選手キャラクタの形態およびカードのレア度希少価値の高さを☆の多さで示したものなどを表記したデジタル選手カードとして画面上に表示される。プレイヤは、ゲームを進行させながら選手カードを集め、自分だけのオリジナルチームを結成し、他のプレイヤと対戦してランキングを競うことができる。また、プレイヤは、集めた選手カード同士を合成することによって選手カード選手キャラクタの能力を向上させるすなわち、選手を育成することができ、より強いチーム作りを目指してゲームを楽しむことができるようになっている。このような野球ゲームにおいて、各プレイヤのゲーム情報を管理するゲーム情報管理手段51は、図5に示すように、プレイヤ情報記憶手段51a、レベル情報記憶手段51bゲームレベル記憶手段、所有選手カード記憶手段51c、所有ポイント記憶手段51d、所有コイン記憶手段51e、所有アイテム記憶手段51f、試合結果記憶手段51gおよびランキング記憶手段51hなどを備えている。図7には、ゲーム情報管理手段51の各記憶手段51a~51hがデータベースサーバ2に記憶して管理する、各プレイヤのゲーム情報の一例この例ではプレイヤID=000001の1人分のゲーム情報を示している。プレイヤ情報記憶手段51aは、各プレイヤを一意に識別するプレイヤIDと対応付けて、ログインID、パスワード、プレイヤ名ゲーム内で使用するニックネーム等、チーム名等の各プレイヤに関するプレイヤ情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。ここで、ログインIDおよびパスワードは、各プレイヤが端末装置3を操作してゲームサーバ1にアクセスしたときのログイン認証に用いられる。プレイヤ名およびチーム名は、プレイヤがゲームサービスを受けるための会員登録をした際や、ゲームを初めて実行した際に、プレイヤが自ら設定した任意の情報である。プレイヤ名およびチーム名は、必要に応じてゲーム画面に表示される。レベル情報記憶手段51bは、プレイヤIDと対応付けて、ゲームレベルとしてのプレイヤのレベルや所属リーグのレベル等のレベル情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。本野球ゲームでは、例えば、プレイヤがゲームを進行させることにより経験値が蓄積され、当該経験値が一定量に達することによりプレイヤのレベルがアップするようになっている。また、本野球ゲームでは、例えば、複数の異なるレベルのリーグが存在し、各プレイヤのチームが何れかのリーグに所属して、同リーグの他のプレイヤのチームと自動で試合リーグ戦を行うようになっている。また、このリーグ戦の成績に応じて、異なるリーグに所属するプレイヤのチーム同士の入替戦が自動で実行され、プレイヤのチームが所属するリーグレベルが変化するようになっている。レベル情報記憶手段51bは、このプレイヤのレベルや所属リーグのレベルを、プレイヤIDと対応付けて記憶する。所有選手カード記憶手段51cは、プレイヤIDと対応付けて、ゲーム内でプレイヤが獲得して所有している選手カードの情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。この選手カードの情報の例としては、選手カードを一意に識別するための識別情報選手カードID、選手の能力の高さを示す能力値およびレギュラー選手フラグなどがある。図7では、3つの能力項目能力1~3に対して選手の能力値を設定できる例を示している。能力項目の例としては、選手カードが野手の場合は、能力1~3を打撃、走力、守備等とすることができ、また選手カードが投手の場合は、能力1~3を球威、制球、変化等とすることができる。能力項目はこの例に限らず、増減可能である。レギュラー選手フラグとは、プレイヤが所有している選手カードのうち、他のプレイヤのチームとの試合に出場するレギュラー選手チームオーダーに組み込まれた選手であるか、それともレギュラー選手以外の控え選手であるかを判別するフラグであり、これが1のときレギュラー選手の選手カードとして登録されていることを示す。プレイヤは、端末装置3を操作することにより、所有している選手カードからレギュラー選手を選択したり、チームオーダーを設定したりすることができるようになっている。また、データベースサーバ2には、選手カードIDと対応付けられて、選手カードの画像データ、選手名、ポジション、所属球団、能力値合成により強化されていない初期値などが記憶された選手カードデータベースが存在し、ゲーム情報管理手段51は、所有選手カード記憶手段51cが記憶している選手カードIDに基づいて、当該選手カードIDに対応する選手カードの画像データ等を取得できるようになっている。所有ポイント記憶手段51dは、プレイヤIDと対応付けて、ゲーム内でプレイヤが所有している各種ポイントポイントに準ずる値などを含むを、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。本ゲームにおいては、様々なゲームモードが存在し、ゲームモードに応じて様々なポイントを獲得したり、獲得したポイントを使用したりできるようになっている。図7に示すように、ポイントの例としては、上述の経験値の他、行動力ポイント、運営コスト、強化ポイント、交流ポイントなどがある。行動力ポイントは、当該行動力ポイントを消費しながら選手カードを探索して選手をスカウトするというスカウトモードで使用される。運営コストは、他のプレイヤを指定して個別対戦の試合を行う試合モードで使用されるものであり、試合を運営する場合に必要なコストポイントという位置付けで、当該個別対戦を行うことにより消費される。例えば、ゲーム中に消費されて減った行動力ポイントや運営コストは、時間の経過により回復する例えば、3分経過する毎に1ポイントずつ回復するようにしたり、前記経験値が一定量に達してプレイヤのレベルがアップすることにより回復するようにしたりできる。また、前記の強化ポイントは、プレイヤが所有する選手カード同士を合成することによって選手カードの能力を向上させる強化モードで使用されるものであり、当該合成を行うことにより消費される。この強化ポイントは、例えばスカウトモードの実行や試合モードの実行等によって獲得できるようにすることができる。また、前記交流ポイントは、プレイヤが他のプレイヤ特に仲間プレイヤと挨拶等の交流を行うことによって獲得できるポイントである。交流の具体例等の詳細については後述する。この交流ポイントは、例えば、ゲームサーバ1が管理している全ての選手カードの中から乱数等に基づく抽選で所定枚数例えば1枚の選手カードを獲得できる抽選モードで使用可能であり、所定の交流ポイントにつき1回の選手カード抽選を受けることができる。所有コイン記憶手段51eは、プレイヤIDと対応付けて、ゲーム内でプレイヤが所有しているコイン前記ポイントとは別のゲーム内通貨を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。このコインは、例えば、課金対象のアイテムを獲得する等の際に必要となるものである。所有アイテム記憶手段51fは、プレイヤIDと対応付けて、ゲーム内でプレイヤが獲得したアイテムを、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。図7に示すように、アイテムの例としては、回復アイテム、パズルカードのピース、フェイクカードなどがある。回復アイテムは、ゲーム中に消費して減った前述の行動力ポイントおよび/または運営コストを、時間の経過を待たずに一瞬で最大値まで回復させるアイテムである。例えば、回復アイテムは、前記コインを消費して購入したり、ゲーム内で所定のボーナス条件を満たしたりすることにより獲得できる。パズルカードのピースは、所定数のピース例えばP1~P6の6つのピースを全部集めてパズルカードを完成させることで強力な能力値の高い選手カードを入手することができるアイテムである。例えば、パズルカードのピースは、前記スカウトモードの実行時に乱数等に基づく抽選で当選した場合に獲得でき、また前記試合モードで他のプレイヤが所有しているピースを狙って対戦して勝利した場合に、当該対戦相手のプレイヤから奪取できるようになっている。フェイクカードは、前記パズルカードのピースにセットしておくことにより、前記試合モードの対戦で他のプレイヤに負けても、狙われたピースを一度だけ奪取されないようにできるアイテムである。例えば、フェイクカードは、前記コインを消費して購入したり、ゲーム内で所定のボーナス条件を満たしたりすることにより獲得できる。試合結果記憶手段51gは、プレイヤIDと対応付けて、プレイヤのチームが他のプレイヤのチームと対戦した試合を一意に特定するための試合IDを、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。ここで、試合IDにより一意に特定される試合は、プレイヤが対戦相手を指定して行う個別対戦の試合、およびゲームサーバ1により自動で行われるリーグ戦の試合を含む。また、データベースサーバ2は、試合IDと対応付けられて、試合日時現実世界の試合開始または終了の時間、勝利したチームのプレイヤID、敗北したチームのプレイヤID、対戦スコア、勝利投手キャラクタ、敗戦投手キャラクタ、本塁打を打った選手キャラクタ、試合寸評情報などの試合結果に関する情報が記憶された試合データベースを備えている。そして、ゲーム情報管理手段51は、試合結果記憶手段51gが記憶している試合IDに基づいて、当該試合IDに対応する試合結果に関する情報を、試合データベースから取得できるようになっている。ランキング記憶手段51hは、プレイヤIDと対応付けて、前記リーグ戦や入れ替え戦におけるプレイヤのチームの勝利数および敗戦数、ならびに勝利数敗戦数に基づく所属リーグ内の順位などのランキング情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。例えば、リーグ戦が現実世界における月曜日~金曜日の各日の所定時間に所定の試合数例えば各日12試合自動的に行われ、また、入れ替え戦が現実世界における土曜日および日曜日の所定時間に所定の試合数例えば各日12試合自動的に行われるものとする。この場合、図7に示すように、ランキング記憶手段51hは、現実世界の月曜日~日曜日の各日についてのランキング情報を記憶し、毎週、ランキング情報を最新の情報に更新する。次に、図4に示すゲーム進行手段52について説明する。ゲーム進行手段52は、プレイヤによる端末装置3に対する操作に応じてゲームを実行し、当該実行結果に応じたゲーム画面データを生成してこれを端末装置3に送信し、端末装置3にプレイヤの操作に応じたゲーム画面を表示させることによってゲームを進行させる機能を有する。図4に示すように、このゲーム進行手段52は、ゲーム実行手段52aと、ゲーム画面生成手段52bと、ゲーム画面送信手段52cとを備えている。プレイヤの端末装置3のウェブブラウザによってゲーム画面が表示されているとき、プレイヤがゲーム画面上の選択可能なボタンオブジェクトやハイパーリンクが設定された文字列等を選択する操作を行った場合、当該操作に応じたゲーム画面のリクエストが端末装置3のウェブブラウザによってゲームサーバ1へ送信される。このリクエストを受信したゲームサーバ1では、ゲーム実行手段52aが、当該リクエストに応じてプレイヤのゲーム情報を読み出して演算やデータ処理を行うことによってゲームを実行する。例えば、対戦モードで他のプレイヤのチームと対戦するという操作がプレイヤによって行われた場合を例に挙げると、ゲーム実行手段52aは、対戦を行う両プレイヤのプレイヤIDに対応した両チームの選手カード情報試合に出場するレギュラー選手の選手カード情報をデータベースサーバ2から読み出す。そして、ゲーム実行手段52aは、両チームの選手カードの能力値等に基づいて、勝敗を決定する演算を行う。この勝敗決定の演算の例としては、単純に両チームの選手カードの能力値の合計が高い方を勝利チームとしてもよいし、能力値の合計が高い方のチームが勝利する確率を高くして勝利チームを確率演算により求めてもよい。また、ゲーム実行手段52aは、勝敗を決定する演算の前に、チームを構成する選手カードの組み合わせに基づいて、勝敗に影響を与える様々な効果演出を発生させるか否かを決定する演算を行ってもよい。ゲーム画面生成手段52bは、ゲーム実行手段52aによる実行結果に応じて、例えばHTMLデータからなるゲーム画面データを生成する。HTMLデータには、データベースサーバ2から読み出された選手カード等の画像データを含めてもよい。また、HTMLデータには、端末装置3のウェブブラウザのプラグインによって動作するスクリプトプログラムが埋め込まれていてもよい。ゲームサーバ1から提供されたスクリプトが端末装置3で実行される場合は、端末装置3で表示されるゲーム画面を動画とすることも可能である。ゲーム画面送信手段52cは、ゲーム画面生成手段52bにより生成されたゲーム画面データHTMLデータ等を、ゲーム画面のリクエストに対するレスポンスとしてプレイヤの端末装置3へ送信する。このゲーム画面データを受信したプレイヤの端末装置3では、ウェブブラウザによって表示部35にゲーム画面が表示される。次に、認証手段53について説明する。認証手段53は、ゲームサービスを受けようとするプレイヤが端末装置3を操作してゲームサーバ1にアクセスログインしようとした際、当該プレイヤのゲーム参加資格の有無を判断してログイン認証を行う。この認証の例としては、プレイヤIDと対応付けられたログインIDおよびパスワードに基づく認証がある。例えば、プレイヤが初めてゲームサービスを利用するときに、会員情報としてログインID任意の英数文字やメールアドレス等およびパスワードをゲームサーバ1に登録する。そして、次回からのゲームサーバ1へのログイン時には、プレイヤが端末装置3を操作してログインIDおよびパスワードをゲームサーバ1へ送信する。このとき、ゲームサーバ1の認証手段53が、プレイヤの端末装置3から受信したログインIDおよびパスワードの組み合わせが登録済みであるか否かを判断し、ログイン認証を行う。また、SNSのシステムに本ゲームシステムを組み込む場合、SNSの会員登録情報ログインIDおよびパスワードをそのまま本ゲームシステムのゲームサービスを受けるための利用登録情報としてもよい。例えば、プレイヤの端末装置3がSNSサーバにログインしている状態で、ゲームサーバ1が管理するゲームサイトに最初にアクセスした際、SNSサーバからゲームサーバ1へ自動的にプレイヤのログインIDおよびパスワードが転送され、これによってプレイヤが改めてログインIDおよびパスワードを登録することなくゲームサービスの利用登録ができるようにしてもよい。また、プレイヤがゲームサーバ1にアクセスする度にログインIDおよびパスワードを入力する手間を省略できるように、端末装置3である携帯電話やスマートフォンの個体識別番号電話番号とは別の端末を一意に識別するための情報、または契約者固有ID端末の契約者を一意に識別するための情報であって、機種変更を行っても契約者が同一である限りは変更されないIDを利用した認証を行ってもよい。すなわち、プレイヤが端末装置3を操作して会員登録した際に、当該端末装置3から送信されてくるデータに含まれる個体識別番号または契約者固有IDをゲームサーバ1が取得し、ログインIDおよびパスワードとともに、当該個体識別番号または契約者固有IDもプレイヤIDと対応付けてデータベースサーバ2に記憶しておくのである。そして、認証手段53は、端末装置3からアクセス要求を受けた際には、個体識別番号または契約者固有IDが登録済みであるか否かを判断してログイン認証を行う。これにより、ゲームサーバ1へのアクセス時には、プレイヤはログインIDおよびパスワードの入力を省略してログインすることが可能となる。また、プレイヤがゲームサーバ1にアクセスする度にログインIDおよびパスワードを入力する手間を省略できる別の方法としては、HTTPcookieの情報以下、Cookieと称するを利用する方法もある。すなわち、プレイヤが端末装置3を操作して会員登録した際に、ゲームサーバ1がログインIDおよびパスワードに対応した個体識別情報を発行してデータベースサーバ2へ登録するとともに、当該個体識別情報をCookieとして端末装置3へ送信する。このとき、端末装置3のブラウザは、受信したCookieを端末装置3内へ記憶する。次回からのゲームサーバ1へのアクセスの際には、端末装置3のブラウザがページ閲覧要求とともにCookieをゲームサーバ1へ送信するので、認証手段53は、端末装置3からアクセス要求を受けた際には、Cookieの個体識別番号が登録済みであるか否かを判断してログイン認証を行うことができる。次に、仲間管理手段54について説明する。仲間管理手段54は、仲間関係が成立している2人のプレイヤを関係付けた仲間情報をデータベースサーバ2記憶装置に記憶する仲間情報記憶手段54aを備えている。図8には、仲間情報記憶手段54aがデータベースサーバ2に記憶する仲間情報の一例を示している。図8に示すように、仲間情報記憶手段54aは、ある2人のプレイヤ間で仲間関係が成立したときに、仲間申請をしたプレイヤのプレイヤIDと当該仲間申請を承認したプレイヤのプレイヤIDとを関係付けた仲間情報をデータベースサーバ2へ記憶する。そして、仲間管理手段54は、各仲間情報にこれらを一意に識別するための仲間情報IDを付加し、仲間情報IDに基づいて仲間管理を行う。図8の例では、仲間申請したプレイヤID=000001のプレイヤAと、それを承認したプレイヤID=000002のプレイヤBとの2人のプレイヤを関係付けた仲間情報が、仲間情報ID=1の仲間情報としてデータベースサーバ2に登録されている。これにより、プレイヤAにとってプレイヤBは仲間関係にある仲間プレイヤであり、プレイヤBにとってもプレイヤAは仲間プレイヤとなる。また、各プレイヤは複数の仲間を作ることができ、各プレイヤを中心とする仲間グループを構成することが可能である。図8の例では、プレイヤID=000001のプレイヤAは、プレイヤID=000005および000035のプレイヤとも仲間関係を構築している。そして、仲間管理手段54は、各プレイヤを中心とする仲間グループに所属する仲間関係にある仲間プレイヤの情報をデータベースサーバ2に記憶して、プレイヤ毎の仲間管理を行う。図9aには、仲間管理手段54がデータベースサーバ2に記憶している仲間情報等に基づいて管理している、各プレイヤの仲間に関する情報の一例を示している。仲間管理手段54の仲間情報記憶手段54aは、プレイヤIDと対応付けて、仲間数の上限の情報、すでに仲間の関係になっている仲間プレイヤのプレイヤID、仲間申請中のプレイヤのプレイヤID、および仲間申請を受けているが未承認のプレイヤのプレイヤIDなどの仲間に関する情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。図9aの例では、プレイヤID=000001のプレイヤ1人分の仲間に関する情報を示しており、仲間数の上限は45人、当該プレイヤの仲間プレイヤは10人、仲間申請中のプレイヤは1人、仲間申請を受けているが未承認のプレイヤは0人である。本実施の形態の野球ゲームでは、仲間をつくることによって、後述の仲間成立ポイント付与手段103により、仲間関係になった両プレイヤにボーナスポイントが付与される例えば、前記行動力ポイントや運営コストの最大値を所定ポイントだけ増加させることができる。また、仲間プレイヤと協力して試合をしたり、仲間同士で選手カードのプレゼントや応援を行ったりすることで、ゲームを有利に進めることができるゲーム仕様となっている。このようにゲーム内で仲間をつくることによるメリットをプレイヤに付与することにより、仲間を作ることを促進している。但し、各プレイヤが他のプレイヤと仲間関係を構築することができる仲間数には上限を設定することができる。仲間数の上限としては、各プレイヤに共通の1つの上限例えば、50人を設けることができる。あるいは、各プレイヤのゲームの進行度合いに応じて、仲間数の上限が所定範囲例えば10人~99人の範囲で変動するようにしてもよい。本実施の形態では、仲間数の上限が10人~99人の範囲で変動し、プレイヤのレベルが高くなるほど、仲間数の上限が大きくなるようにしている。これにより、プレイヤは、より多くの仲間を作ってゲームを有利にするために、ゲームを継続的に進めてレベルアップを図ろうとする動機付けを与えられることになる。仲間情報記憶手段54aは、プレイヤIDと対応付けて、各プレイヤの仲間数の上限を記憶しており、仲間管理手段54が各プレイヤの仲間数の上限を管理する。本実施の形態において、2人のプレイヤが仲間になるには、両プレイヤの何れか一方が、他方のプレイヤに対してゲームサーバ1を介して仲間申請を行う。この仲間申請の操作例としては、先ず、仲間を作ろうとするプレイヤが、端末装置3の画面上に仲間候補の対象者をリストアップする操作を行う。このとき、プレイヤは、仲間候補のプレイヤレベルを指定することができる。このプレイヤによる操作に応じて、ゲームサーバ1が仲間候補の対象者をリストアップした画面データを送信することにより、複数の仲間候補がリストアップされた画面がプレイヤの端末装置3に表示される。ここで、プレイヤは、画面上にリストアップされた対象者のプレイヤレベルや所属リーグレベル等を確認し、仲間にしたいプレイヤを選択して仲間申請の操作を行う。例えば、プレイヤID=000001のプレイヤAが、プレイヤID=000002のプレイヤBに対して仲間申請の操作を行った場合を考える。図9aに示すように、この操作に応じてゲームサーバ1の仲間情報記憶手段54aは、仲間申請を行ったプレイヤAのゲーム情報として、当該プレイヤAのプレイヤID=000001と対応付けて、被申請者であるプレイヤBのプレイヤID=000002を、申請中のプレイヤIDとして記憶する。さらに、図10aに示すように、仲間情報記憶手段54aは、被申請者であるプレイヤBのゲーム情報として、当該プレイヤBのプレイヤID=000002と対応付けて、仲間申請を行ったプレイヤAのプレイヤID=000001を、未承認のプレイヤIDとして記憶する。そして、ゲームサーバ1は、その後、プレイヤBの端末装置3がゲームサーバ1にログインしたときに、プレイヤAから仲間申請があった旨を通知する。そして、仲間申請を受けたプレイヤBは、ゲームサーバ1から受信したプレイヤAのプレイヤレベルや所属リーグレベル等の情報を、端末装置3の画面上で確認し、仲間として承認するか拒否するかを選択する操作を行う。ここで、プレイヤBが仲間として承認する操作を行った場合、この操作に応じてゲームサーバ1の仲間管理手段54は、プレイヤAとプレイヤBとの仲間関係を成立させ、図8に示すように両プレイヤABのプレイヤIDを関係付けた仲間情報をデータベースサーバ2に登録する。そして、仲間情報記憶手段54aは、図9bに示すように、プレイヤAのゲーム情報として、当該プレイヤAのプレイヤID=000001と対応付けて、プレイヤBのプレイヤID=000002を、仲間プレイヤIDとして記憶し、申請中のプレイヤIDからプレイヤBのプレイヤIDを削除する。さらに、図10bに示すように、仲間情報記憶手段54aは、プレイヤBのプレイヤID=000002と対応付けて、プレイヤAのプレイヤID=000001を、仲間プレイヤIDとして記憶し、未承認のプレイヤIDからプレイヤAのプレイヤIDを削除する。そして、ゲームサーバ1は、その後、プレイヤAの端末装置3がゲームサーバ1にログインしたときに、プレイヤBから仲間の承認があった旨を通知する。また、仲間情報記憶手段54aは、2人の仲間関係が解除された後も、当該2人のプレイヤを関係付けた過去の仲間情報を保持記憶する。以下に、仲間情報記憶手段54aが過去の仲間情報を保持する形態について説明する。図11Aは、仲間情報記憶手段54aがデータベースサーバ2の所定の記憶領域に記憶している、現在および過去の仲間情報の一部を抜粋して示したものである。この図11Aには、全プレイヤの中から、現在仲間関係にある一対のプレイヤ及び過去に仲間関係にあった一対のプレイヤが、併せてリストアップされている。図11Aに例示するように、仲間情報記憶手段54aは、仲間関係が解除された2人の仲間情報に、仲間解除フラグを立てて、過去の仲間情報として保持するようになっている。図11Aの例では、仲間解除フラグとして1が設定されている仲間情報が過去の仲間情報であり、仲間解除フラグが0の仲間情報が現在成立中の仲間情報である。ここで、プレイヤID=000001のプレイヤAに注目して、図11Aの説明を続ける。プレイヤAの仲間情報とは、仲間申請をしたプレイヤIDまたは承認したプレイヤIDの何れかに000001が含まれている仲間情報であり、仲間情報ID=1、2、3、22、23、81の仲間情報がこれに該当する。これらのうち、仲間情報ID=3、81の仲間情報は、仲間解除フラグが0であるため、現在の仲間情報である。よって、プレイヤID=000035、000110の各プレイヤは、プレイヤAの現在の仲間プレイヤである。一方、仲間情報ID=1、2、22、23の仲間情報は、仲間解除フラグが1であるため、過去の仲間情報である。よって、プレイヤID=000002、000005、000010、000012の各プレイヤは、プレイヤAの過去の仲間プレイヤである。このように、仲間情報に仲間解除フラグを付加することにより、現在の仲間情報と過去の仲間情報とを区別できるようにして、過去の仲間情報を保持することができる。この形態では、僅か1ビットの仲間解除フラグを設定するだけで、現在の仲間情報の内容をそのまま援用して過去の仲間情報を保持できるので、好ましい形態である。過去の仲間情報を保持する他の形態としては、現在の仲間情報とは別に、過去の仲間情報をデータベースサーバ2に新規登録する形態もある。例えば、図11Bに示すように、仲間情報記憶手段54aは、2人のプレイヤ間の仲間関係が解除されたときに、当該2人のプレイヤの各々のプレイヤIDを関係付けた過去の仲間情報を、データベースサーバ2へ記憶する。図11Bの例では、仲間関係を自主的に解除したプレイヤIDと、相手から仲間関係を自主的に解除されたプレイヤIDとを関係付けて記憶する。そして、仲間管理手段54は、過去の仲間情報を一意に識別するための識別情報過去の仲間情報IDを付加し、過去の仲間情報IDに基づいた管理を行う。ここで、プレイヤID=000001のプレイヤAに注目して、図11Bの説明を続ける。プレイヤAの過去の仲間情報とは、解除したプレイヤIDまたは解除されたプレイヤIDの何れかに000001が含まれている情報であり、過去の仲間情報ID=100001~100004の情報がこれに該当する。よって、プレイヤID=000002、000005、000010、000012の各プレイヤは、プレイヤAの過去の仲間プレイヤである。後述するように、仲間情報記憶手段54aが記憶している過去の仲間情報は、仲間履歴送信手段101が過去の仲間プレイヤを表示させるための情報を端末装置3へ送信するときに使用される。また、仲間情報記憶手段54aは、仲間関係にある2人のプレイヤの一方が仲間関係を自主的に解除した場合、当該2人のプレイヤのうち仲間関係を自主的に解除した側のプレイヤと、相手から仲間関係を自主的に解除された側のプレイヤとを区別して記憶することが望ましい。これにより、解除した側のプレイヤの情報のみ、または解除された側のプレイヤの情報のみを、それぞれ抽出することができる。解除した側と解除された側とを区別して記憶する形態としては、解除した側と解除された側とを区別するための識別情報を過去の仲間情報に付加する形態や、解除した側を記憶する領域と解除された側を記憶する領域とを別に設ける形態などが考えられる。これらの形態の詳細を、以下に説明する。例えば図11Aに示すように、解除した側と解除された側とを区別するための識別情報として、1ビットの解除者情報を、過去の仲間情報に付加する。この解除者情報が1の場合、図11A中の仲間申請をしたプレイヤIDとして登録されているプレイヤIDのプレイヤが、仲間関係を自主的に解除したプレイヤであることを示す。また、解除者情報が0の場合、図11A中の承認したプレイヤIDとして登録されているプレイヤIDのプレイヤが、仲間関係を自主的に解除したプレイヤであることを示す。なお仲間解除フラグが1の情報が過去の仲間情報であるため、仲間解除フラグが1の場合にのみ解除者情報が有効となる仲間解除フラグが0の情報は、現在成立中の仲間情報であるため、解除者情報は無効である。以下に、具体例を説明する。ここでは、図11Aに記載の仲間情報ID=1の仲間情報を例に挙げる。仲間情報ID=1の仲間情報は、仲間解除フラグが1に設定されているので、プレイヤID=000001、000002の2人の仲間関係が既に解除されている過去の仲間情報である。そして、解除者情報が1に設定されているので、図11A中の仲間申請をしたプレイヤIDの欄に記載されている000001のプレイヤIDを有するプレイヤAが、仲間関係を自主的に解除した側のプレイヤである。そして、図11A中の承認したプレイヤIDの欄に記載されている000002のプレイヤIDを有するプレイヤBが、解除された側のプレイヤである。また、図11Aに記載の仲間情報ID=2の仲間情報の場合は、仲間解除フラグが1なので過去の仲間情報であり、且つ解除者情報が0に設定されているので、図11A中の承認したプレイヤIDの欄に記載されている000002のプレイヤIDを有するプレイヤBが、解除した側のプレイヤである。そして、図11A中の仲間申請をしたプレイヤIDの欄に記載されている000001のプレイヤIDを有するプレイヤAが、解除された側のプレイヤである。なお、図11Aの例において、解除者情報に代えて、解除した側または解除された側の少なくとも一方のプレイヤIDを記憶することにより、両者を区別する形態も考えられる。ただし、プレイヤIDを記憶するには複数ビットの情報を記憶する必要がある。これに対して、図11Aの解除者情報は、1ビットの情報で解除した側と解除された側を明確に区別できるので、好ましい形態である。また、図11Bに例示するように、現在の仲間情報とは別に過去の仲間情報をデータベースサーバ2等に記憶する形態において、解除したプレイヤのプレイヤIDを記憶する領域と、解除されたプレイヤのプレイヤIDを記憶する領域とを区別して記憶することにより、両者を明確に区別して記憶することができる。次に、交流手段55について説明する。交流手段55は、プレイヤの端末装置3から、他のプレイヤ特に、仲間プレイヤに対して所定の交流を行う情報を受信し、受信した情報に基づいて、当該プレイヤから当該他のプレイヤに対しての交流処理を実行する機能を備えている。図6に示すように、本実施の形態の交流手段55は、挨拶手段55a、メッセージ伝達手段55b、メッセージ記憶部55c、プレゼント手段55d、対戦協力手段55eおよび交流履歴記憶手段55f等を具備する。挨拶手段55aは、各プレイヤの端末装置3から送信された他のプレイヤ宛の挨拶情報を受信して、当該他のプレイヤへ挨拶情報を伝達する機能を有する。また、メッセージ伝達手段55bは、各プレイヤの端末装置3から送信された他のプレイヤ宛のメッセージを受信するとともに、当該メッセージを当該他のプレイヤへ伝達する機能を有する。このメッセージ伝達手段55bは、メッセージ記憶部55cを備えている。図12には、メッセージ記憶部55cがデータベースサーバ2に記憶して管理する、受信メッセージに関する情報の一例を示している。このメッセージ記憶部55cは、メッセージを受け取った受信側プレイヤのプレイヤIDと対応付けて、送信元のプレイヤID、メッセージの内容、送信日時などのメッセージに関する情報を、受信側のプレイヤのプレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。また、各メッセージに関する情報には、各メッセージを一意に識別するためのメッセージIDが付加されている。図12の例では、プレイヤID=000002の受信側プレイヤ1人分の受信メッセージに関する情報を示しており、当該プレイヤは、プレイヤID=000001のプレイヤからプレゼントありがとう、プレイヤID=000038のプレイヤからおはよう今週のイベント頑張ろう、プレイヤID=000145のプレイヤから今週もよろしくというメッセージをそれぞれ受け取っている。ここで、プレイヤが、自分の仲間プレイヤに対して、挨拶したりメッセージを送ったりする操作の一例を説明する。例えば、プレイヤが端末装置3を操作してメイン画面中の仲間リストボタンを選択すれば、端末装置3から仲間リスト要求がゲームサーバ1へ送信される。ゲームサーバ1は、プレイヤの端末装置3からこの要求を受信して、当該プレイヤの仲間リストを表示させる情報を端末装置3へ送信する。これにより端末装置3には、例えば図14に示すような仲間リスト画面が表示される。この仲間リスト画面には、プレイヤと仲間関係にある仲間プレイヤの情報がリストアップされて表示される。なお、画面に表示しきれない仲間プレイヤの情報については、画面をスクロールするまたは仲間リストの2ページ目以降をゲームサーバ1にリクエストして別画面として表示することができる。この仲間リスト画面内にはリストアップされた仲間プレイヤ毎の情報表示領域が設けられており、各情報表示領域には、仲間プレイヤのゲーム情報81プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等、当該プレイヤの分身的なキャラクタであるアバター82、当該プレイヤが所有するリーダーの選手カード83などとともに、挨拶ボタン84というオブジェクトも表示される。そして、プレイヤがこの挨拶ボタン84を選択操作することで、自分の仲間プレイヤに対してゲーム内で仮想的に挨拶することができるようになっている。例えば、プレイヤAが仲間プレイヤBの挨拶ボタン84を選択操作した場合、端末装置3から挨拶情報が送信され、この挨拶情報を受信した挨拶手段55aが、仲間プレイヤBの端末装置3へプレイヤAから挨拶があったことを伝達する。ここで、挨拶とは、上記のようにゲーム内で仮想的に行うことができる簡易的な交流の総称であり、エール応援を送る、ガッツやる気を送る、ウインクする、微笑む、手を振る等、別の表現を用いた簡易的な交流も含まれる。プレイヤは、仲間プレイヤに挨拶だけすることもできるが、以下に説明するように、挨拶と同時にメッセージを送ることもできる。プレイヤの端末装置3における操作により挨拶ボタン84が選択された場合、当該操作が端末装置3からゲームサーバ1へ伝えられる。その後、ゲームサーバ1からは、例えば図15に示すメッセージ入力画面のデータが端末装置3へ送信され、端末装置3に当該メッセージ入力画面が表示される。このメッセージ入力画面には、例えば、仲間プレイヤ図15の例ではプレイヤBに対して挨拶した旨を示す文章等が表示されるとともに、メッセージ入力領域85および送信ボタン86というオブジェクトも表示される。そして、プレイヤは、端末装置3を操作してメッセージ入力領域85に任意のメッセージを入力し、送信ボタン86を選択することによって、端末装置3からは仲間プレイヤ宛のメッセージがゲームサーバ1へ送信される。図15ではプレゼントありがとうというメッセージをプレイヤが入力した例を示している。なお、データベースサーバ2における記憶容量を考慮して、メッセージ入力領域85に入力できる文字に制限例えば全角30文字以内を設けてもよい。なお、メッセージ入力画面には、仲間プレイヤこの例ではプレイヤBのページへ遷移するためのハイパーリンク87が表示されており、このリンクを選択することにより当該仲間プレイヤのゲーム情報の詳細が記載されたページを表示できる。また、メッセージ入力画面には、仲間リストへ遷移するためのハイパーリンク88やメイン画面へ遷移するためのハイパーリンク89なども表示されており、これらのリンクを選択することにより仲間リストやメイン画面に戻れるようになっている。このメッセージ入力画面でのプレイヤの操作により端末装置3からメッセージが送信された場合、ゲームサーバ1では、メッセージ伝達手段55bのメッセージ記憶部55cが、端末装置3から受信した仲間プレイヤ宛のメッセージを、当該仲間プレイヤのプレイヤIDと対応させてデータベースサーバ2に記憶する図12参照。そして、当該仲間プレイヤの端末装置3がゲームサーバ1へアクセスしたとき、ゲームサーバ1のメッセージ伝達手段55bは、メッセージ、送信元のプレイヤ名、送信時間等を表示させる画面データを端末装置3に送信する。これにより、この画面データを受信したプレイヤの端末装置3にはメッセージ等が表示され、他の仲間から受け取ったメッセージを画面で確認できるようになっている。このように、本実施の形態のゲームシステムでは、前記図14および図15に例示するようなコミュニケーションツールを使用して、仲間同士が何時でもコミュニケーションをとることができるようになっている。前記図14および図15の例では、プレイヤの仲間に対してメッセージを送る例を説明したが、仲間関係にはない他のプレイヤに対しても、挨拶したりメッセージを送ったりすることもできる。例えば、仲間候補リストにリストアップされた仲間ではない他のプレイヤに対して、仲間の場合と同様の操作により、挨拶やメッセージを送ることも可能である。プレゼント手段55dは、各プレイヤの端末装置3から送信された他のプレイヤ宛のプレゼントの情報を受信して、当該他のプレイヤへプレゼントを届ける機能を有する。プレゼントの対象としては、プレイヤがゲーム内で所有している選手カードや各種アイテムなどが挙げられる。対戦協力手段55eは、プレイヤプレイヤAとするの端末装置3から、仲間プレイヤに対して対戦協力を要請する情報を受信し、プレイヤAのキャラクタ複数のキャラクタからなるグループやチームでもよいが他のキャラクタと対戦するときに、仲間プレイヤのキャラクタ例えば、リーダーの選手カードを、助っ人としてプレイヤA側に加担させて対戦協力を実行する機能を有する。このように、仲間プレイヤのキャラクタが助っ人としてプレイヤA側に加担して対戦協力することにより、プレイヤA側の戦力が向上するので、当該対戦協力がない場合に比べて、プレイヤAの対戦が有利になる。なお、プレイヤのキャラクタが他のキャラクタと対戦する場合の他のキャラクタとは、他のプレイヤのキャラクタ複数のキャラクタからなるグループやチームでもよい又はゲームサーバ1のCPUが用意したキャラクタ例えば、各ステージの最後に登場するボスキャラクタ等のいずれであってもよい。プレイヤが端末装置3を操作して、助っ人にしたい仲間プレイヤのキャラクタまたは仲間プレイヤを選択すれば、端末装置3からは、選択された仲間プレイヤのキャラクタまたは仲間プレイヤの情報を含む対戦協力要請情報がゲームサーバ1へ送信される。そして、ゲームサーバ1の対戦協力手段55eは、プレイヤの端末装置3から送信された対戦協力要請情報を受信して、当該プレイヤが選択した仲間プレイヤのキャラクタを助っ人として受け付ける。図16Aに、対戦モードにおけるゲーム画面の一例を示している。このゲーム画面には、プレイヤが指定した対戦相手のチーム敵軍の情報91およびプレイヤのチーム自軍の情報92が表示される。対戦相手のチーム敵軍の情報91としては、例えば、対戦相手のプレイヤ名、アバター、選手カード、戦力に関する情報などが表示される。また、プレイヤのチーム自軍の情報92としては、当該プレイヤのプレイヤ名、アバター、選手カード、戦力に関する情報などが表示される。さらに、このゲーム画面の助っ人表示領域93には、助っ人として自軍に協力するキャラクタ等の情報が表示されるようになっている。このゲーム画面は、ゲームサーバ1のゲーム画面生成手段52bにより生成されるとともに、ゲーム画面送信手段52cによりプレイヤの端末装置3へ送信されるものであり、端末装置3の表示部35に表示される。また、助っ人表示領域93には、助っ人を呼ぶボタン93aまたはハイパーリンクが設定された文字列等が表示され、任意の仲間のキャラクタを助っ人として要請できるようになっている。プレイヤが助っ人を呼ぶボタン93aを選択することにより、例えば図16Bに示す助っ人選択画面に遷移する。この助っ人選択画面には、プレイヤと仲間関係にある仲間プレイヤおよび当該仲間プレイヤが有するキャラクタ選手カードがリストアップされて表示される。なお、画面に表示しきれない情報については、画面をスクロールするまたは助っ人選択画面の2ページ目以降をゲームサーバ1にリクエストして別画面として表示することができる。この助っ人選択画面内にはリストアップされた仲間プレイヤ毎の情報表示領域が設けられており、各情報表示領域には、仲間プレイヤの名前94a、仲間プレイヤのアバター94b、仲間プレイヤが有する選手カード94c、選手名94d、当該選手カードの情報選手カードに設定されているレベルや攻撃力等94eなどが表示される。図16Bでは、仲間プレイヤが有する複数の選手カードのうち、リーダーとして設定されている選手カードを助っ人のキャラクタとして選択可能な例を示している。これに限らず、例えば、エース投手や4番打者として設定されている選手カードなどの代表的なキャラクタを、仲間の助っ人として選択可能としてもよい。そして、プレイヤが端末装置3を操作して、例えば仲間プレイヤの名前94aに設定されたハイパーリンク表示部分を選択することにより、助っ人にしたい仲間のキャラクタを選択できるようになっている。例えば、図16Bの助っ人選択画面において、プレイヤAが端末装置3を操作して仲間プレイヤBのキャラクタを助っ人として選択した場合、図16Cに例示するゲーム画面に遷移し、助っ人表示領域93には、プレイヤBの選手カード95が助っ人として表示される。また、助っ人表示領域93には、対戦協力する仲間プレイヤのアバターや対戦協力による戦力アップ情報等も併せて表示される。図16Cの画面例では、対戦協力による戦力アップ情報として攻撃力200が表示されている。なお、プレイヤが仲間の助っ人を選択すれば、ゲームサーバ1において当該仲間の助っ人の情報を当該プレイヤのプレイヤIDと対応付けてデータベースサーバ2記憶装置に記憶する。よって、プレイヤが仲間の助っ人を選択する操作を行えば、次回の対戦においても、前回選択した仲間のキャラクタが助っ人として設定されるようにすることができる。また、仲間のキャラクタが助っ人として設定されているとき、助っ人表示領域93には、助っ人を変更するボタン96またはハイパーリンクが設定された文字列等が表示されるようになっている。プレイヤがこのボタン96を選択することにより、図16Bの助っ人選択画面に遷移し、助っ人にしたい仲間のキャラクタを選択し直すことができるようになっている。図16Aまたは図16Cの対戦モードの画面において、プレイヤが対戦開始ボタン97を選択する操作を行うことにより、プレイヤの端末装置3からは対戦コマンドがゲームサーバ1へ送信され、ゲームサーバ1において対戦処理が実行される。そして、助っ人表示領域93に仲間のキャラクタが助っ人として表示されているときに対戦開始ボタン97を選択する操作が行われることにより、対戦コマンドと併せて仲間プレイヤに対して対戦協力を要請する情報が、端末装置3からゲームサーバ1に送信される。この場合、仲間プレイヤのキャラクタを助っ人としてプレイヤ側に加担させる対戦協力が実行されることになる。つぎに、交流履歴記憶手段55fについて説明する。交流履歴記憶手段55fは、各プレイヤの交流履歴をデータベースサーバ2記憶装置に記憶する。交流手段55において、プレイヤから他のプレイヤに対しての交流処理が実行されたとき、交流履歴記憶手段55fは、交流履歴として、例えば図43に示すように、交流情報ID、交流をしたプレイヤID、交流相手のプレイヤID、交流種別、交流処理実行時の時間情報等を記憶する。交流種別とは、挨拶、メッセージ、プレゼント、対戦協力等の、具体的な交流の内容を示すものである。交流処理実行時の時間情報としては、年、月、日、時、分、秒等の時間情報を記憶するが、ここで記憶する時間の単位は任意に設定できる。なお、交流手段55が実行する交流処理の対象となる交流は、上述の挨拶、メッセージの送信、プレゼント、協力対戦の助っ人依頼に限定されるものではなく、仲間のプレイヤ同士で行われる様々な交流を含めることができる。交流のその他の例としては、合同練習などがある。合同練習とは、交流の一種であり、プレイヤがゲーム内で仮想的に仲間プレイヤとともに行う練習である。合同練習を希望するプレイヤは、仲間プレイヤを指定して合同練習を申込み、当該仲間プレイヤが所定期間内に例えば、申込みがあったその日のうちにゲームにアクセスログインした場合に合同練習が成立する。次に、仲間履歴送信手段101について説明する。仲間履歴送信手段101は、プレイヤが操作する端末装置3からの要求に応じて、仲間情報記憶手段54aに記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置3へ送信する機能を有する。例えば、プレイヤが端末装置3を操作してメイン画面中の過去の仲間リストボタンを選択すれば、端末装置3から過去の仲間リスト要求がゲームサーバ1へ送信される。仲間履歴送信手段101は、プレイヤの端末装置3からこの要求を受信して、当該プレイヤの過去の仲間リストを表示させる情報過去の仲間リストの画面データを端末装置3へ送信する。仲間履歴送信手段101が送信した情報を受信した端末装置3には、例えば図17に示すような過去の仲間リスト画面が表示される。この過去の仲間リスト画面には、プレイヤと過去に仲間関係にあった仲間プレイヤの情報がリストアップされて表示される。なお、画面に表示しきれない過去の仲間プレイヤの情報については、画面をスクロールするまたはリストの2ページ目以降をゲームサーバ1にリクエストして別画面として表示することができる。後述するように、図17に示す過去の仲間リスト画面中にリストアップされる過去の仲間プレイヤは、当該画面を表示している端末装置3を有するプレイヤが過去に自主的に仲間解除した仲間プレイヤであってもよい。この過去の仲間リスト画面内には、リストアップされた過去の仲間プレイヤ毎の情報表示領域が設けられており、各情報表示領域には、過去の仲間プレイヤの現在のゲーム情報201プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等、当該プレイヤの分身的なキャラクタであるアバター202、当該プレイヤが所有するリーダーの選手カード203などとともに、復活申請ボタン204というオブジェクトも表示される。そして、プレイヤが仲間関係を復活させたい過去の仲間プレイヤを選択するこの例では、過去の仲間プレイヤの復活申請ボタン204を選択する操作を行うことにより、当該操作の情報が端末装置3からゲームサーバ1へと送信される。この操作の情報をプレイヤの端末装置3から受信した仲間復活申請手段102は、当該プレイヤから選択された過去の仲間プレイヤへの仲間関係復活の申請処理を実行するようになっている。図17に示すように、過去の仲間リストの中に、リストアップされた過去の仲間プレイヤの各々の現在のゲームレベルプレイヤのレベル、所属リーグのレベル等を表示させることが望ましい。これを実現するゲームサーバ1の構成は次の通りである。すなわち、ゲームレベル記憶手段図5に示すレベル情報記憶手段51b等が、各プレイヤのゲームレベルを記憶装置データベースサーバ2等に記憶している。そして、仲間履歴送信手段101は、プレイヤが操作する端末装置3からの要求に応じて、仲間情報記憶手段54aに記憶されている当該プレイヤの過去の仲間情報および前記ゲームレベル記憶手段に記憶されている当該プレイヤの過去の仲間プレイヤの現在のゲームレベルをそれぞれ読み出し、当該プレイヤの過去の仲間プレイヤを表示させるための情報とともに、当該過去の仲間プレイヤの現在のゲームレベルを表示させるための情報を、前記端末装置3へ送信する。なお、ゲームレベルの詳細については、後述する。これにより、プレイヤは、端末装置3の表示された過去の仲間プレイヤの現在のゲームレベルを確認しながら、もう一度、仲間関係を築くか否かを判断することができる。例えば、以前はあまりゲームにアクセスしていなかった他のプレイヤXとの仲間関係を解除したが、当該プレイヤXの現在のゲームレベルは以前よりも格段に高くなっていることが確認できた場合、当該プレイヤXともう一度仲間になってもよいという判断ができる。また、プレイヤが仲間復活申請を行う際に、相手に対するメッセージを添付することができるようにするすなわち、メッセージ付きの仲間復活申請を可能とすることが望ましい。例えば、プレイヤが復活申請ボタン204を選択する操作を行うことにより、ゲームサーバ1からは、図15に類似したメッセージ入力画面のデータが端末装置3へ送信されるようにする。このようなメッセージ入力画面で、プレイヤが仲間復活申請の相手に対するメッセージを入力してゲームサーバ1へ送信すれば、メッセージ付きの仲間復活申請ができる。なお、メッセージの添付は任意事項であり、メッセージを添付しない場合でも仲間復活申請は可能である。図19には、仲間復活申請を管理するための記憶情報の一例を示している。仲間関係復活の申請処理を実行する仲間復活申請手段102は、図19に例示するように、仲間情報を管理するための仲間情報IDと対応づけて、復活申請をしたプレイヤのプレイヤIDをデータベースサーバ2に登録する。図19における仲間情報ID=1の例では、プレイヤID=000001のプレイヤAが復活申請した例を示している。そして、仲間復活申請手段102は、申請相手の過去の仲間プレイヤBの端末装置3に対して、プレイヤAから復活申請があったことを表示させるための情報を送信する。なお、メッセージ付き仲間復活申請であった場合には、メッセージ伝達手段55bと協働して、仲間復活申請手段102が申請者からのメッセージも併せて送信する。なお、これらの送信は、プレイヤAが復活申請をした後、過去の仲間プレイヤBの端末装置3がゲームサーバ1に最初にアクセスしたときに行われる。仲間復活申請手段102が送信した情報を受信した過去の仲間プレイヤBの端末装置3では、例えば、図18に示すような承認拒否選択画面が表示される。この画面には、仲間復活申請をしたプレイヤAの現在のゲーム情報211プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等、当該プレイヤのアバター212、当該プレイヤが所有するリーダーの選手カード213などとともに、承認ボタン214、拒否ボタン215というオブジェクトも表示される。また、メッセージ付き仲間復活申請であった場合には、申請者からのメッセージも併せて表示される。ここで、プレイヤが拒否ボタン215を選択することにより、仲間関係の復活を拒否することもできる。一方、プレイヤBがプレイヤAとの仲間関係の復活を承認する場合、承認ボタン214を選択する操作を行うことにより、当該操作の情報がプレイヤBの端末装置3からゲームサーバ1へと送信される。この操作の情報を受信したゲームサーバ1の仲間管理手段54は、プレイヤBからの承認を受け付け、仲間関係復活処理を実行するようになっている。仲間関係復活処理を実行する仲間管理手段54は、例えば図19に示すように、仲間情報を管理するための仲間情報IDと対応づけて記憶されている仲間解除フラグを0に設定する図19中の仲間情報ID=22を参照。また、このとき、復活承認したプレイヤのプレイヤIDおよび仲間関係の復活時間復活日等の情報を併せてデータベースサーバ2に記憶していてもよい。ゲームシステムの動作上記の構成において、本発明の実施の形態に係るゲームシステムの動作例を、図20のフローチャートを参照しながら以下に説明する。図20は、プレイヤが端末装置3を操作してゲームサーバ1にアクセスしてゲームサービスを受けるときの、端末装置3およびゲームサーバ1の処理の流れを示すものである。プレイヤがゲームサービスを受ける場合、先ず、端末装置3の操作入力部40を操作してウェブブラウザを起動するS11。その後、プレイヤは、ゲームサーバ1が管理するゲームサイトにアクセスする操作を行い、これにより、端末装置3からゲームサーバ1へアクセスリクエストが送信されるS12。このとき、ゲームサーバ1は、端末装置3からのアクセスに対するログイン認証を行いS21、ゲームサービスの利用登録がなされているプレイヤからのアクセスであることを確認する。その後、ゲームサーバ1は、HTML等で記述されたメイン画面データを端末装置3に送信するS22。なお、メイン画面とは別のトップ画面がある場合は、まずトップ画面を送信してもよい。そして、メイン画面データを受信した端末装置3では、ウェブブラウザが当該データを解釈し、メイン画面を表示部35に表示させるS13。図13に例示するように、メイン画面には、プレイヤのチーム名70、プレイヤが所有する選手カードの中からリーダーとして選択された選手カード71の画像、プレイヤのゲーム情報72プレイヤのレベル、行動力ポイント、運営コスト、強化ポイント、交流ポイント、所有する選手カードの数、仲間人数などが表示される。また、スカウト、オーダー、強化、抽選、試合の各モードを選択するためのボタン群73なども表示される。さらに、このメイン画面には、端末装置3の方向キーやタッチパネル等を操作して画面をスクロールさせることによって、図示しない各種メニューボタン、仲間の動き情報、他のプレイヤからのメッセージなど、様々なオブジェクトや情報が表示されるようになっている。ここでプレイヤが、画面に表示されている選択可能なボタン等のオブジェクトやハイパーリンクを選択する操作をすると、当該操作に応じた画面のリクエストが端末装置3からゲームサーバ1へ送信されるS14。このリクエストを受信したゲームサーバ1は、プレイヤの操作に応じた演算処理やデータ処理を行ってゲームを実行しS23、実行結果を反映させたゲーム画面データを端末装置3へ送信するS24。そして、画面データを受信した端末装置3では、ウェブブラウザが当該データを解釈し、ゲーム画面を表示部35に表示させるS15。以降は、プレイヤの端末装置3においては前記のS14およびS15が繰り返され、ゲームサーバ1においては前記のS23およびS24が繰り返され、これにより、端末装置3の画面に表示されている選択可能なボタン等をプレイヤが選択する度に、端末装置3のゲーム画面が次々と切り替わり、ゲームを進行させることができる。その後、プレイヤが端末装置3を操作してゲーム画面を閉じた場合S16、ゲームサーバ1はログアウト処理を行うS25。例えば、プレイヤがウェブブラウザを閉じた場合、ゲームサーバ1はセッションタイムアウト後にログアウト処理を行う。ところで、本ゲームシステムにおいては、プレイヤがゲームサーバ1からログアウトした場合であっても、ゲームサーバ1側で当該プレイヤのゲーム情報を読み出してゲームを進行させることができる。例えば、ログアウトしているプレイヤのチームに対して、ログインしている他のプレイヤが対戦個別対戦を仕掛けてくることもある。この場合も、ゲームサーバ1のゲーム進行手段52は、プレイヤがログインしているか否かに依らずに、各プレイヤのゲーム情報をデータベースサーバ2から読み出して対戦を実行し、その実行結果を反映させて各プレイヤのゲーム情報を更新する。また、リーグ戦モードでは、プレイヤによる端末装置3の操作なしに、ゲームサーバ1のゲーム進行手段52が、各プレイヤのゲーム情報をデータベースサーバ2から読み出して、自動でリーグ戦の試合を実行する。このように、プレイヤがゲームサーバ1からログアウトしているときに実行された対戦の結果は、その後、プレイヤがゲームサーバ1にアクセスしたときに画面で確認することができる。ゲーム管理装置の動作次に、本発明の実施の形態に係るゲーム管理装置のより詳細な動作例を、図21ないし図24のフローチャートを参照しながら説明する。図21は、ある1人のプレイヤを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している各々のプレイヤに対して同様の処理が行われる。図21に示すように、ゲームサーバ1の認証手段53は、プレイヤの端末装置3からアクセス要求を受けたときS31でYES、端末装置3から送信されてきたログインIDパスワード、または携帯電話端末の個体識別番号等に基づいて、アクセスを許可するか否かを判断するログイン認証を行うS32。ここで、アクセスを許可しない場合S32でNO、ゲームサーバ1は、端末装置3にゲームサービスの利用登録を促す画面データを送信するS33。一方、アクセスを許可する場合S32でYES、アクセス情報ログを記憶するS34。そして、ゲームサーバ1は、アクセスを許可したプレイヤの端末装置3に、メイン画面データまたはトップ画面データを送信するS35。その後、プレイヤの端末装置3から送信されてくるプレイヤのゲーム操作に応じた画面リクエストを受信するとS36でYES、ゲーム実行手段52aは、当該画面リクエストに応じた演算処理やデータ処理を行ってゲームを実行するS37。その後、ゲームサーバ1はゲームの実行によりプレイヤのゲーム情報を更新する必要があるか否かを判断しS38、更新の必要がある場合S38でYES、データベースサーバ2に記憶されているプレイヤのゲーム情報を更新するS39。例えば、プレイヤのゲーム操作が他のプレイヤとの個別対戦を行う操作であった場合、当該対戦が実行された結果、試合結果の情報、運営コスト、強化ポイント、アイテム等のプレイヤのゲーム情報が更新されることになる。一方、例えば、プレイヤのゲーム操作がリーグ戦の結果確認の操作であった場合、当該操作に応じたゲームの実行処理としてはリーグ戦の結果情報をデータベースサーバ2から読み出すデータ処理だけであって、当該処理の前後でプレイヤのゲーム情報に変化はなく、よってプレイヤのゲーム情報を更新する必要はないS38でNO。その後、ゲーム画面生成手段52bがゲームの実行結果を反映させたゲーム画面データを生成しS40、ゲーム画面送信手段52cが当該ゲーム画面データをプレイヤの端末装置3へ送信するS41。その後、プレイヤの端末装置3がログアウトしたか否かが判断されS42、端末装置3がログアウトするまで、前記S36~S41の処理が繰り返されることで、ゲームが進行していく。次に、図22を参照して、ゲームサーバ1における仲間解除時の処理例について説明する。図22のフローチャートは、仲間関係が成立している2人のプレイヤを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している全ての仲間同士のペアに対して同様の処理が行われることになる。プレイヤは、自分の仲間プレイヤとの仲間関係をいつでも自主的に解除することができる。例えば、図14に示す仲間リストから仲間関係を解除したい仲間プレイヤを選択して所定の操作を行うことにより、当該仲間プレイヤとの仲間関係を解除できる。仲間関係の成立時とは異なり、その解除には相手側の承認は不要である。仲間解除の操作が行われた場合、プレイヤの端末装置3からゲームサーバ1へ仲間解除要求が送信される。図22に示すように、ゲームサーバ1がプレイヤの端末装置3から仲間解除要求を受信したときS51でYES、仲間管理手段54は仲間関係の解除処理を実行するS52。例えば、仲間管理手段54の仲間情報記憶手段54aが、図11Aに示すように、仲間関係が解除された2人の仲間情報に仲間解除フラグを立てる。これにより、2人の仲間関係が解除された後も、当該2人のプレイヤを関係付けた過去の仲間情報が保持されるS53。その後、仲間管理手段54は、図11Aに例示する解除者情報を設定して、仲間関係が解除された2人のうち何れのプレイヤが自主的に仲間を解除したのかを識別できるようにするS54。このS54の処理は、省くこともできる。なお、仲間関係の解除処理の他の例としては、仲間関係が解除された2人の仲間情報を削除しS52、図11Bに示すように仲間関係を自主的に解除した側と解除された側の2人のプレイヤを関係付けた過去の仲間情報を新規に記憶してもよいS53およびS54。その後、ゲームサーバ1は、仲間関係が解除された2人のプレイヤの端末装置3に対して、仲間関係解除の旨を報知するための情報解除の旨を含む画面データ等を送信し、当該2人のプレイヤに仲間関係解除の事実を報知するS55。報知の例としては、ゲーム画面の中に仲間関係解除の旨を表示することの他に、音声による報知や画面表示と音声とを併用した報知も考えられる。音声による報知は、ゲームサーバ1からプレイヤの端末装置3へ送信する画面データHTMLデータ等に音声データを含ませることにより実現できる。なお、ゲームサーバ1が、仲間関係の解除を報知するためには、プレイヤの端末装置3がゲームサーバ1にアクセスしている必要がある。仲間関係を自主的に解除した側のプレイヤの端末装置3は、解除時においてゲームサーバ1にアクセスしているので直ぐに報知できるが、解除された側のプレイヤの端末装置3はゲームサーバ1にアクセスしているとは限らない。よって、ゲームサーバ1は、仲間関係の解除処理を実行した後、仲間関係が解除された側のプレイヤの端末装置3がゲームサーバ1に最初にアクセスしたときに、S55の報知処理を実行することになる。次に、図23を参照して、仲間関係の復活について説明する。図23は、プレイヤAがプレイヤBに対して仲間復活申請を行う例を示している。また、プレイヤAの端末装置を端末装置3A、プレイヤBの端末装置を端末装置3Bとしている。プレイヤは、自分の過去の仲間リストをいつでも端末装置3の画面上で確認することができる。例えば、プレイヤAが端末装置3Aを操作してメイン画面中の過去の仲間リストボタンを選択すれば、端末装置3Aから過去の仲間リスト要求がゲームサーバ1へ送信されるS61。ゲームサーバ1ではこの要求を受信しS71、仲間情報記憶手段54aが記憶している、プレイヤAの過去の仲間情報を読み出すS72。そして、仲間履歴送信手段101は、プレイヤAの過去の仲間リストを表示させる情報過去の仲間リストの画面データを端末装置3Aへ送信するS73。この仲間履歴送信手段101が送信した情報を受信した端末装置3Aには、例えば図17に示すような過去の仲間リスト画面が表示されることになるS62。これにより、プレイヤAは、端末装置3Aの画面上で過去の仲間プレイヤを確認しながら、仲間関係を復帰したい相手を検討することができる。そして、過去の仲間リストが表示されている端末装置3AにてプレイヤAが仲間関係を復活させたい過去の仲間プレイヤを選択する操作を行うことによりS63、当該操作の情報が端末装置3Aからゲームサーバ1へと送信される。なお、この操作の際、プレイヤAがプレイヤBに対するメッセージを入力すれば、当該メッセージも端末装置3Aからゲームサーバ1へと送信され、メッセージ付き仲間復活申請とすることができる。この例では、プレイヤAが過去の仲間プレイヤBを選択する操作を行ったものとする。ゲームサーバ1ではこの操作の情報を受信しS74、仲間復活申請手段102がプレイヤAからプレイヤBへの仲間関係復活の申請処理を実行するS75。例えば、仲間復活申請手段102は、図19に例示するように、プレイヤABを関係付けた過去の仲間情報仲間情報ID=1の情報と対応付けて、復活申請をしたプレイヤAのプレイヤID=000001を記憶する。さらに、仲間復活申請手段102は、プレイヤAが復活申請をした後、プレイヤBの端末装置3Bがゲームサーバ1に最初にアクセスしたときに、端末装置3Bに対してプレイヤAから復活申請があったことを表示させるための情報を送信する。なお、メッセージ付き仲間復活申請の場合には、メッセージ伝達手段55bと協働して、仲間復活申請手段102が、プレイヤAからのメッセージも併せて端末装置3Bへ送信する。仲間復活申請手段102が送信した情報を受信したプレイヤBの端末装置3BではS81、例えば図18に示すような承認拒否選択画面が表示される。なお、メッセージ付き仲間復活申請の場合には、併せてプレイヤAからのメッセージも表示される。プレイヤBは、プレイヤAからの仲間復活申請を承認することも拒否することも可能であるが、図23では承認する場合の動作を例示している。プレイヤBが承認ボタン214を選択する操作を行うことによりS82、当該操作の情報がプレイヤBの端末装置3からゲームサーバ1へと送信される。この操作の情報を受信したゲームサーバ1ではS76、仲間管理手段54がプレイヤAとBとの仲間関係の復活処理を実行するS77。例えば、仲間管理手段54は、プレイヤAとBとを関係付けた仲間情報の仲間解除フラグを0に設定する。このとき、図19に示す復活承認したプレイヤIDおよび復活時間復活日等の情報を記憶していてもよい。その後、ゲームサーバ1は、仲間関係が復活した2人のプレイヤABの端末装置3A3Bに対して、仲間関係が復活した旨を報知するための復活通知復活の旨を含む画面データ等を送信するS78。この復活通知を受信した端末装置3A3BではS64、S83、プレイヤAB間の仲間関係が復活した旨が表示される。上記のように、本実施の形態のゲームサーバ1を適用することにより、プレイヤは、自分の端末装置3に過去の仲間リストを表示させることができ、所望の相手に対して簡単に仲間復活申請を行うことができるようになっている。これにより、プレイヤは、過去の仲間プレイヤと仲間関係を再構築する機会が与えられる。よって、以下に例示するような従来ではできなかったことや新たなゲームの楽しみ方ができるようになる。例えば、プレイヤが、仲間であった相手との仲間関係を誤操作等により誤って解除してしまった場合、その後、同じ相手と仲間関係を再構築する機会が得られる。また、何らかの理由例えば、海外出張や受験に専念等でプレイヤが一時的に暫くゲームから離れる必要が生じた場合、次のような対応が可能である。すなわち、ゲームから離れている期間中は仲間プレイヤとの仲間関係を解消し、その後、ゲームを再開するときに、過去の仲間プレイヤに仲間復活申請を行い、仲間関係を復活させる。この場合、プレイヤが仲間プレイヤとの仲間関係を解消する前に、当該相手にメッセージでその理由および後日復活申請を行う旨を伝えておき、相手にそれを納得してもらえば、仲間復活申請に対して相手から承認が得られ易く、仲間関係の復活を円滑に行うことができるようになる。この対応は、特に仲間数に上限例えば50人が設定されているゲームにおいて有効である。すなわち、もしプレイヤがゲームから離れている間も仲間関係を維持し続ければ、仲間プレイヤの限られた仲間枠を無駄に使ってしまうことになり兼ねない。そこで、プレイヤがゲームから離れている期間中の仲間関係を解消すれば、仲間プレイヤは空いた仲間枠を使って、他のプレイヤと交流等を楽しむことができる。また、仲間数に上限が設定されているゲームにおいて、次のようなことも可能になる。すなわち、仲間数が上限に達しているプレイヤが、新しい他のプレイヤYと仲間になるために、仲間プレイヤXとの関係を一旦解除する。その後、プレイヤYと思うような交流ができなかったような場合には、プレイヤYとの関係を解除した上で、プレイヤXに仲間復活申請を行い、仲間関係を復活させる。このように、本実施の形態のゲームサーバ1を適用すれば、プレイヤは、限られた仲間枠を有効に使った新なゲームの楽しみ方ができる。ところで、仲間復活申請を可能としたことにより、仲間関係を自主的に解除した側のプレイヤが、折角解除した過去の仲間プレイヤから、後日、望まないかたちで仲間復活申請を受ける可能性がある。これを回避するための構成を以下に説明する。仲間情報記憶手段54aは、図11Aまたは図11Bに例示するように、仲間関係を自主的に解除した側のプレイヤと、相手から仲間関係を自主的に解除された側のプレイヤと、を解除者情報等で区別して記憶している。そして、仲間履歴送信手段101は、プレイヤが操作する端末装置3からの要求に応じて、仲間情報記憶手段54aに記憶されている当該プレイヤの過去の仲間情報のうち当該プレイヤが仲間関係を自主的に解除した場合の情報を読み出し、当該プレイヤが仲間関係を自主的に解除した過去の仲間プレイヤを表示させるための情報を当該端末装置3へ送信するようになっている。この構成のゲームサーバ1における仲間履歴送信処理を、図24を参照して以下に説明する。ここでは、プレイヤAが操作する端末装置3からの要求に応じて、図11Aに示す仲間情報から必要な情報を抽出して処理するゲームサーバ1の動作例を説明する。プレイヤAが端末装置3を操作して、例えばメイン画面中の過去の仲間リストボタンを選択すれば、プレイヤAの端末装置3から過去の仲間リスト要求がゲームサーバ1へ送信される。この要求をゲームサーバ1が受信すればS91でYES、先ず、図11Aに示す仲間情報から対象となるプレイヤAプレイヤID=000001の仲間情報を抽出するS92。すなわち、図11Aに示す仲間情報の中から、仲間申請をしたプレイヤIDまたは承認したプレイヤIDの何れかに000001が含まれている仲間情報を抽出する。このステップS92により、仲間情報ID=1、2、3、22、23、81の仲間情報が抽出される。さらに、ゲームサーバ1は、ステップS92で抽出した仲間情報のうち、仲間解除フラグが1に設定されている過去の仲間情報を抽出するS93。このステップS93により、仲間情報ID=1、2、22、23の仲間情報が抽出される。なお、前記ステップS92およびS93は、データベースの複数条件検索により同時に実行することもできる。さらに、ゲームサーバ1は、ステップS93で抽出した過去の仲間情報のうち、プレイヤAが自主的に解除した過去の仲間情報を抽出するS94。すなわち、プレイヤAのプレイヤID=000001が、仲間申請をしたプレイヤIDの欄に含まれる場合には、解除者情報が1の情報を抽出する。また、プレイヤAのプレイヤID=000001が、承認をしたプレイヤIDの欄に含まれる場合には、解除者情報が0の情報を抽出する。このS94により、仲間情報ID=1、23の仲間情報が抽出される。このステップS94も、データベースの複数条件検索により、S92およびS93と同時に実行することもできる。その後、ゲームサーバ1は、ステップS94で抽出した過去の仲間情報の中から、プレイヤAの相手の過去の仲間のプレイヤIDをリストアップするS95。このステップS95により、プレイヤAが自主的に解除した過去の仲間プレイヤのプレイヤIDとして、000002および000012がリストアップされる。その後、仲間履歴送信手段101は、ステップS95でリストアップしたプレイヤIDに基づいて、プレイヤAが仲間関係を自主的に解除した過去の仲間プレイヤのみからなる過去の仲間リスト画面データを生成し、それをプレイヤの端末装置3に送信するS96。これにより、プレイヤの端末装置3には、当該プレイヤが自ら仲間関係を解除した過去の仲間プレイヤのみが表示され、当該プレイヤが相手から仲間関係を解除された場合の相手情報は表示されないことになる。よって、仲間関係を解除された側のプレイヤは、解除した側のプレイヤに対する仲間復活申請ができない。これにより、解除した側のプレイヤが、解除された側のプレイヤから、望まない仲間復活申請を受けるといった事態を効果的に回避できる。ところで、良心的な仲間プレイヤは、仲間関係の解除前に、その理由をメッセージで伝えると考えられる。もし、理由も言わないで、突然、相手から仲間関係が解除された場合、自分を解除した相手に対して、仲間復活申請をしようとは思わないプレイヤが多いと考えられる。このような事情を考慮すると、プレイヤにとっては、自分を解除した相手が省かれた状態で過去の仲間プレイヤが端末装置3に表示されることにより、所望の相手を見つけ易くなるという効果も期待できる。ゲーム管理装置の他の構成例次に、仲間復活申請を受けたプレイヤの承認を促進し、仲間関係の再構築がされ易いようにすることができるゲーム管理装置の構成について、図25の機能ブロック図等を参照しながら説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。本実施の形態のゲームサーバ1ゲーム管理装置は、図4に示した各手段に加えて、仲間成立ポイント付与手段103をさらに備えている。この仲間成立ポイント付与手段103は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。仲間成立ポイント付与手段103は、2人のプレイヤ間で仲間関係が成立したときに、ボーナスとして少なくとも承認した側のプレイヤに対して、所定の仲間成立ポイントを付与する機能を有する。すなわち、仲間成立ポイント付与手段103は、仲間申請側および承認側の両方のプレイヤにそれぞれ仲間成立ポイントを付与してもよいし、承認側のプレイヤのみに仲間成立ポイントを付与してもよい。本実施の形態では、仲間申請側および承認側の両方のプレイヤに所定の仲間成立ポイントを付与する構成について説明する。本実施の形態では、仲間成立ポイント付与手段103が、新規で仲間関係が成立した2人のプレイヤに、例えば3ポイントずつ仲間成立ポイントを付与するようになっている。ここで、仲間成立ポイントは、例えば、上述の行動力ポイントまたは運営コストの最大値を高めるポイントとして利用できるようになっている。仲間関係が成立した2人のプレイヤに仲間成立ポイントが付与されたことにより、ゲーム情報管理手段51の所有ポイント記憶手段51dが記憶している当該2人のポイントは更新される。なお、何れか一方のプレイヤにより仲間関係が解除された場合には、仲間成立ポイントの増減を回避するため、仲間関係成立時に当該2人のプレイヤに対して付与された仲間成立ポイントと同じ3ポイントがゲーム情報管理手段51により削減されるようにしてもよい。仲間関係が解除されたときにポイントを削減するか否かは任意に設定できる。また、本実施の形態の仲間成立ポイント付与手段103は、仲間復活申請を承認した過去の仲間プレイヤに対して付与するポイントを、復活申請ではなく通常の仲間申請を承認したプレイヤに対して付与するポイントよりも高くするようになっている。一例を挙げると、仲間成立ポイント付与手段103は、通常の仲間申請を承認したプレイヤには3ポイント、仲間復活申請を承認した過去の仲間プレイヤに対しては5ポイントを、それぞれ付与する。なお、上記の各ポイントの値はこれらに限らず、通常の仲間申請を承認した場合より仲間復活申請を承認した場合の方が付与されるポイントが多いという条件を満たせば、任意の値に設定できる。本実施の形態のゲームサーバ1における仲間成立ポイント付与処理の例を、図26を参照して以下に説明する。プレイヤが承認の操作を行った場合S101、その承認が仲間復活申請に対する承認であるか否かが判定されるS102。ここで、その承認が仲間復活申請ではなく通常の仲間申請に対する承認の場合S102でNO、仲間管理手段54は、通常の仲間関係の成立処理を実行するS103。この場合、仲間成立ポイント付与手段103は、承認した側のプレイヤに対して、例えば3ポイントの仲間成立ポイントを付与するS104。一方、前記の承認が仲間復活申請に対する承認の場合S102でYES、仲間管理手段54は、仲間関係復活処理を実行するS105。この場合、仲間成立ポイント付与手段103は、承認した側のプレイヤに対して、例えば5ポイントの仲間成立ポイントを付与するS106。S104またはS106の処理の後、仲間成立ポイント付与手段103は、申請した側のプレイヤに対して、例えば3ポイントの仲間成立ポイントを付与するS107。このように、本実施の形態では、通常の仲間申請を承認した場合より仲間復活申請を承認した場合の方がより多くのポイントを付与することにより、仲間復活申請を受けたプレイヤの承認を促進している。これにより、仲間関係が復活され易くなり、本ゲームサーバ1が有する仲間関係を復活させる機能の実効性を高めている。ところで、仲間復活申請を承認した方が、通常の仲間申請を承認するより多くのポイントが得られる場合、仲間同士でポイントの獲得だけを狙って仲間関係の解除と復活とを短期間で繰り返すという不適正な事態が生じる可能性がある。例えば、仲間同士でメッセージのやり取りをしながら、ポイント狙いの仲間関係の復活の繰り返しを画策することも起こり得る。そこで、このような事態を回避するための構成について、以下に説明する。図25に示すように、ゲームサーバ1は、復活時間記憶手段104および再復活制限手段105をさらに備えている。これらの手段は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。復活時間記憶手段104は、仲間復活申請手段102が実行した仲間復活申請処理による申請をプレイヤの過去の仲間プレイヤが承認して仲間関係が復活した場合、仲間関係の復活時間の情報を記憶手段データベースサーバ2に記憶する機能を有する。ここで、復活時間としては、年、月、日、時、分、秒等の時間情報を記憶するが、ここで記憶する時間の単位は任意に設定できる。例えば、図19に示すように、復活時間記憶手段104は、仲間関係が復活した2人のプレイヤを関係付けた仲間情報IDと対応付けて、復活時間復活日等をデータベースサーバ2に記憶する。また、再復活制限手段105は、復活時間記憶手段104が記憶した2人のプレイヤの復活時間から所定期間例えば3か月が経過するまでは、当該2人のプレイヤ間での仲間関係の再度の復活を許可しないという機能を有する。例えば、2人のプレイヤが仲間関係を復活させた後、所定期間が経過する前に、何れか一方のプレイヤにより仲間復活申請の操作が行われても、その申請を受け付けずに、仲間復活申請処理が実行されないようにする。そして、前記の所定期間が経過した後は、仲間復活申請の操作が行われたときに仲間復活申請処理が実行されるようにする。あるいは、前記の所定期間が経過する前であっても仲間復活申請処理については実行されるようにするが、前記の所定期間が経過する前にプレイヤにより仲間復活申請に対する承認の操作が行われた場合には、その承認を受け付けずに、仲間復活処理が実行されないようにする。そして、前記の所定期間が経過した後は、仲間復活申請に対する承認の操作が行われたときに仲間復活処理が実行されるようにする。ここで、仲間関係の復活後に再復活が禁止される期間である前記の所定期間としては、任意の期間を設定可能である。例えば、所定期間を一定の期間例えば3か月等としてもよい。あるいは、図19に示すように、2人のプレイヤの仲間関係の復活回数を記憶装置データベースサーバ2等に記憶しておき、復活回数に応じて所定期間を変動させてもよい。例えば、前記の所定回数を、2人のプレイヤの復活回数が2回目なら2か月、3回目なら3か月、4回目なら4か月に設定するというように、復活回数が多くなるほど所定期間を長く設定するようにする。これにより、ポイント狙いによる仲間関係の復活の繰り返しが多くなればなるほど、復活が禁止される期間も長くなるので、不適正なポイント狙いのプレイヤの行動を、効果的に抑制することができる。本実施の形態のゲームサーバ1における再復活制限処理の例を、図27および図28を参照して以下に説明する。なお、図27および図28のフローチャートは、仲間現在または過去の仲間同士の2人のプレイヤを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している全ての仲間同士のペアに対して同様の処理が行われることになる。図27に示すように、2人のプレイヤ間で仲間復活申請およびその承認が行われたことにより、仲間復活処理が実行されたときS111でYES、復活時間記憶手段104が復活時間をデータベースサーバ2に記憶するS112。その後、仲間関係が復活した2人のプレイヤの何れか一方が解除操作を行って当該2人の仲間関係が解除された場合S113でYES、所定期間が経過するまで仲間関係の再復活を制限する処理S114~S117のループ処理に移行する。すなわち、何れか一方のプレイヤにより仲間復活申請の操作が行われてもS114でYES、復活時間から所定期間が経過していなければS115でNO、再復活制限手段105は仲間復活申請を許可しないS116。これにより、仲間復活申請手段102による仲間復活申請処理が実行されることはない。この場合、ゲームサーバ1は、仲間復活申請の操作を行ったプレイヤの端末装置3に、前回の復活から所定期間が経過するまでは再復活は禁止されている旨を報知するための情報を送信するS117。一方、何れか一方のプレイヤにより仲間復活申請の操作が行われたときにS114でYES、既に復活時間から所定期間が経過しているのであればS115でYES、仲間復活申請手段102が仲間復活申請処理を実行するS118。その後、他方のプレイヤが仲間復活申請を承認したときS119、仲間管理手段54が仲間復活処理を実行するS120。その後は、S112の処理に戻って復活時間記憶手段104が復活時間を記憶更新する。上記のように、一度仲間関係を復帰させた2人のプレイヤは、その復帰後、所定期間が経過するまで、仲間復活申請が受け付けられないので仲間関係の再度の復活が制限される。次に、ゲームサーバ1における再復活制限処理の他の例を、図28を参照して説明する。2人のプレイヤの仲間復活処理が実行されたときS111でYES、復活時間記憶手段104が復活時間をデータベースサーバ2に記憶するS112。その後、2人の仲間関係が解除されS113でYES、さらにその後、何れか一方のプレイヤにより仲間復活申請の操作が行われた場合S121でYES、復活時間から所定期間が経過しているか否かにかかわらずに、仲間復活申請手段102が仲間復活申請処理を実行するS122。この仲間復活申請処理において、仲間復活申請を受けたプレイヤの端末装置3に、前回の復活から所定期間が経過するまで承認できない旨を報知するための情報を送信する。また、仲間復活申請の操作を行ったプレイヤの端末装置3にも、前回の復活から所定期間が経過するまで相手が承認できない旨を報知するための情報を送信することが望ましい。その後、他方のプレイヤから承認の操作が行われてもS123でYES、復活時間から所定期間が経過していなければS124でNO、再復活制限手段105は承認を許可しないS125。これにより仲間管理手段54による仲間復活処理が実行されることはない。この場合、ゲームサーバ1は、承認の操作を行ったプレイヤの端末装置3に、前回の復活から所定期間が経過するまでは再復活は禁止されている旨を報知するための情報を送信するS126。一方、承認の操作が行われたときにS123でYES、既に復活時間から所定期間が経過しているのであればS124でYES、仲間管理手段54が仲間復活処理を実行するS127。その後は、S112の処理に戻って復活時間記憶手段104が復活時間を記憶更新する。上記のように、一度仲間関係を復帰させた2人のプレイヤは、その復帰後、所定期間が経過するまで、承認が受け付けられないので仲間関係の再度の復活が制限される。本実施の形態の構成により、2人のプレイヤが仲間関係の解除と復活とを繰り返すことによる不適正なポイント狙いを画策しても、一度仲間関係を復活させた後は、所定期間例えば3か月が経過するまで再度の復活ができなくなる。よって、仲間同士でポイントの獲得だけを狙って仲間関係の解除と復活とを短期間で繰り返すという不適正なプレイヤの行動を、効果的に抑制することができる。次に、仲間同士でポイントの獲得だけを狙って仲間関係の解除と復活とを短期間で繰り返す事態を回避するための他の構成について、以下に説明する。仲間履歴送信手段101は、復活時間記憶手段104が記憶した2人のプレイヤの復活時間から所定期間例えば3か月が経過するまでは、当該2人のプレイヤの仲間関係が再度解除された場合であっても、当該2人のプレイヤのうちの一方のプレイヤが操作する端末装置3からの要求に応じて過去の仲間プレイヤを表示させるための情報を当該端末装置3へ送信するときに、送信する情報の中に他方のプレイヤの情報を含めない機能を有する。この仲間履歴送信手段101が実行する仲間履歴送信処理の一例を、図29のフローチャートに示す。プレイヤが端末装置3を操作して、例えばメイン画面中の過去の仲間リストボタンを選択すれば、端末装置3から過去の仲間リスト要求がゲームサーバ1へ送信される。この要求をゲームサーバ1が受信すればS131でYES、仲間履歴送信手段101は、仲間情報記憶手段54aが記憶しているプレイヤの過去の仲間情報のうち、復活時間記憶手段104が記憶している当該プレイヤの復活時間から所定期間例えば3か月が経過した過去の仲間情報のみを抽出して読み出すS132。そして、仲間履歴送信手段101は、復活時間から所定期間を経過していない過去の仲間プレイヤを含まない過去の仲間リスト画面データを、プレイヤの端末装置3に送信するS133。また、図30のフローチャートには、仲間現在または過去の仲間同士の2人のプレイヤを対象としたゲームサーバ1における再復活制限処理の流れを示している。2人のプレイヤの仲間復活処理が実行されたときS111でYES、復活時間記憶手段104が復活時間をデータベースサーバ2に記憶するS112。その後、2人の仲間関係が解除されS113でYES、さらにその後、2人のプレイヤの何れか一方のプレイヤの端末装置3において過去の仲間リストを要求する操作過去の仲間リストボタンの選択等が行われた場合S141でYESは、当該2人のプレイヤの復活時間から所定期間が経過しているか否かで以降の処理が分岐されるS142。ここで、2人のプレイヤの復活時間から所定期間が経過していなければS142でNO、仲間履歴送信手段101は、相手のプレイヤを含まない過去の仲間リスト画面データを、プレイヤの端末装置3に送信するS143。一方、2人のプレイヤの復活時間から所定期間が経過している場合S142でYES、仲間履歴送信手段101は、相手のプレイヤを含む過去の仲間リスト画面データを、プレイヤの端末装置3に送信するS144。本実施の形態の構成により、2人のプレイヤが仲間関係の解消と復活とを繰り返すことによる不適正なポイント狙いを画策しても、一度仲間関係を復活させた後は、所定期間例えば3か月が経過するまで、お互い相手のプレイヤが過去の仲間プレイヤとして端末装置3に表示されないので、仲間復活申請ができなくなる。よって、仲間同士でポイントの獲得だけを狙って仲間関係の解消と復活とを短期間で繰り返すという不適正なプレイヤの行動を、効果的に抑制することができる。次に、仲間同士でポイントの獲得だけを狙って仲間関係の解除と復活とを短期間で繰り返す事態を回避するためのさらに他の構成について、以下に説明する。図25に示すように、ゲームサーバ1は、2人のプレイヤの仲間関係の復活回数を記憶装置データベースサーバ2に記憶する復活回数記憶手段106を備えている。例えば、図19に示すように、復活回数記憶手段106は、仲間関係が復活した2人のプレイヤを関係付けた仲間情報IDと対応付けて、復活回数をデータベースサーバ2に記憶する。そして、再復活制限手段105は、2人のプレイヤの復活回数が所定回数例えば5回に達した場合、当該2人の所定回数を超えての再度の復活を許可しない。本ゲームサーバ1における再復活制限処理の例を、図31を参照して説明する。2人のプレイヤの仲間復活処理が実行されたときS151でYES、復活回数記憶手段106が復活回数Nをデータベースサーバ2に記憶更新するS152。なお、もしも2人のプレイヤの復活回数が所定回数に達した場合、ゲームサーバ1は、当該2人のプレイヤの端末装置3に、これ以上の復活はできない旨を報知するための情報を送信することが望ましい。その後、2人の仲間関係が解除されS153でYES、さらにその後、何れか一方のプレイヤにより仲間復活申請の操作が行われた場合はS154でYES、当該2人の復活回数Nが所定回数未満か否かで以降の処理が分岐されるS155。ここで、2人の復活回数Nが所定回数未満の場合S155でYES、仲間復活申請手段102が仲間復活申請処理を実行するS156。その後、他方のプレイヤが仲間復活申請を承認したときS157、仲間管理手段54が仲間復活処理を実行するS158。その後は、S152の処理に戻って復活回数記憶手段106が復活回数Nを記憶更新する。一方、2人の復活回数Nが所定回数に達している場合S155でNO、再復活制限手段105は仲間復活申請を許可しないS159。これにより、仲間復活申請手段102による仲間復活申請処理が実行されることはない。この場合、ゲームサーバ1は、仲間復活申請の操作を行ったプレイヤの端末装置3に、所定回数の復活を繰り返した相手とはもはや復活できない旨を報知するための情報を送信するS160。これにより、2人のプレイヤが仲間関係の解消と復活とを繰り返すことによる不適正なポイント狙いを画策しても、所定回数を超える復活はできないので、不適正なポイント狙いを抑制することができる。ゲーム管理装置の他の構成例次に、上述の構成仲間復活申請が可能な構成が好適なゲーム管理装置について説明する。このゲーム管理装置は、仲間関係が成立している2人のプレイヤに仲間期間を設定し、その仲間期間が終了したら仲間関係を自動解除する構成を有する。このように、プレイヤによる意図的な解除ではなく、2人のプレイヤに設定された仲間期間の終了により仲間関係が自動解除される場合、仲間関係の解除が多くなる分、仲間関係を復活させたいと考える機会もまた多くなるため、仲間復活申請を簡単な操作で容易に行うことができる上述の構成が好適である。以下に、本実施の形態のゲーム管理装置について、図32の機能ブロック図を参照しながら説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。図32に示すように、ゲームサーバ1ゲーム管理装置は、図4に示した各手段に加えて、仲間期間設定手段56、仲間関係解除手段57および仲間期間報知手段58をさらに備えている。これらの手段56~58は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。仲間期間設定手段56は、仲間関係が成立している2人のプレイヤに対して、プレイヤ間の仲間関係が継続される仲間期間を設定する機能を有する。仲間期間が終了すれば、原則、2人の仲間関係は自動的に解除されることになる。ここで、仲間期間設定手段56が設定する仲間期間の長さとしては、例えば1週間、10日、2週間、1ヶ月など、任意の期間長さに設定可能である。また、仲間期間の長さは固定であってもよいし、例えば設定時にランダムに期間長さを変えてもよい。さらには、プレイヤ間のレベル関係に応じた適切な期間長さを設定するようにしてもよい。本実施の形態では、プレイヤ間のレベル関係に応じた期間長さを設定する構成の仲間期間設定手段56について、以下に説明する。仲間期間設定手段56は、仲間申請をしたプレイヤ第1のプレイヤおよび当該仲間申請を承認したプレイヤ第2のプレイヤの2人のプレイヤ間での仲間関係の成立時に、第1のプレイヤのゲームレベルと第2のプレイヤのゲームレベルとの関係を含む所定条件に基づいて、仲間期間を設定する機能を有する。ここで、仲間期間を決定するために用いられるゲームレベルとは、プレイヤのゲームの進行度合い、熟練度、力量等を直接的または間接的に示す指標情報である。このゲームレベルとしては、aプレイヤ自身のレベル、bプレイヤのゲーム内の所有物のレベル所有物の例:キャラクタ、キャラクタの集合体であるグループチームユニット、アイテム等、cプレイヤのゲーム内の所有物の数所有物の能力値等から算出される値、dプレイヤが達成したステージのレベルや現在所属しているリーグのレベル、等を挙げることができる。前記aの具体例としては、プレイヤがゲームを進行させて経験値を蓄積することによりレベルアップするゲームにおけるプレイヤのレベルがある。また、前記bの具体例としては、プレイヤが所有するキャラクタを練習モード、試合モード、育成モード、合成モード等で使用することによりキャラクタの強化レベルアップを図るゲームにおけるキャラクタのレベルがある。ここで、キャラクタのレベルとは、キャラクタの成長度合い、能力の高さ、強さ等を表す値であればよく、キャラクタの能力値であってもよい。また、前記cの具体例としては、プレイヤがゲームを進行させることによりキャラクタやアイテムを取得するゲームにおいて、プレイヤが所有するキャラクタやアイテムの数の多さを評価する値がある。例えば、プレイヤが所有する所定の能力値以上のキャラクタ選手カードの数をプレイヤのゲームレベルとすることができる。また、前記dの具体例としては、ゲーム内にレベル難易度の異なる複数のステージが設けられており、1つのステージをクリアしたら1つ難易度の高い別のステージに進むようなゲームにおけるプレイヤが達成したステージのレベルがある。また、前記dの他の具体例としては、プレイヤがリーグ戦で上位の成績を獲得することによって、よりレベルの高いリーグに所属できるようなゲームにおける現在所属しているリーグのレベルがある。本実施の形態では、仲間期間を決定するために用いられるゲームレベルとして、前記aプレイヤ自身のレベルを適用した例について以下に説明する。仲間期間設定手段56は、仲間申請をした第1のプレイヤとそれを承認した第2のプレイヤとのレベル関係を含む所定条件に基づいて仲間期間を決定するのであるが、その例を次に説明する。仲間期間設定手段56は、第1のプレイヤよりもゲームレベルが高い第2のプレイヤが仲間申請を承認した場合に設定する仲間期間を、第1のプレイヤとゲームレベルが同じ又は第1のプレイヤよりもゲームレベルが低い第2のプレイヤが仲間申請を承認した場合に設定する仲間期間よりも短くする。その具体例としては、仲間申請をした第1のプレイヤのレベルをL1、それを承認した第2のプレイヤのレベルをL2とした場合、仲間期間設定手段56は、L1<L2のときには5日、L1=L2のときには7日、L1>L2のときには10日の仲間期間とする。なお、仲間期間の日数はこれらに限定されるものではなく、例えばL1<L2のときには1週間、L1=L2のときには2週間、L1>L2のときには3週間とするなど、任意の期間を設定できる。L1<L2の場合とは、第1のプレイヤよりもゲームレベルが高い第2のプレイヤが仲間申請を承認した場合である。この場合は、承認した第2のプレイヤにとって、自分よりも下位レベルのプレイヤ即ち、対戦協力等の貢献度の低いプレイヤと仲間になるのであるから、自分が望むような交流等ができない仲間であった場合には短期間で仲間関係を解消したいと希望することが多い。そこで、L1=L2の場合同レベル間で仲間成立またはL1>L2の場合よりも仲間期間を短くしている。一方、L1>L2の場合とは、第1のプレイヤよりもゲームレベルが低い第2のプレイヤが仲間申請を承認した場合である。この場合は、承認した第2のプレイヤにとって、自分よりも上位レベルのプレイヤ即ち、対戦協力等の貢献度の高いプレイヤと仲間になるのであるから、L1=L2またはL1<L2の場合よりも仲間関係を長く継続したいと希望することが多い。そこで、L1=L2またはL1<L2の場合よりも仲間期間を長くしている。上記のように、仲間申請を承認した側が申請した側よりも上位レベルであるか否かによって仲間期間を変えることにより、承認した側のプレイヤの希望に沿った適切な仲間期間の設定が可能となる。このように、仲間申請をした側のプレイヤではなく、仲間申請を承認した側のプレイヤからみた適切な仲間期間の設定を行う理由は、次の通りである。すなわち、仲間申請をした側のプレイヤにとっては、相手のプレイヤのレベルにかかわらずその相手と仲間になりたいと考えて仲間申請しているはずである。一方、仲間申請を受けたプレイヤにとっては、それを拒否することもできるが、下位プレイヤからの申請だからといって無碍に断れずにその申請を承認してしまい、後で後悔することも従来は多かった。そこで、仲間申請を承認した側のプレイヤからみた適切な仲間期間の設定を行うのである。次に、仲間期間設定手段56による仲間期間決定処理の他の例を説明する。仲間期間設定手段56は、仲間関係が成立したプレイヤ間のレベル差に応じて、仲間期間を設定するようになっている。以下、仲間申請をした第1のプレイヤのレベルをL1、それを承認した第2のプレイヤのレベルをL2、L1とL2との差をレベル差Dとして説明を続ける。また、図33には、レベル差Dと仲間期間との関係を表すテーブルを例示している。このテーブルの情報は、ゲームサーバ1の記憶手段RAM13または補助記憶装置14等に記憶されており、仲間期間設定手段56による処理中に参照される。まず、仲間申請した第1のプレイヤよりもレベルが高い第2のプレイヤが仲間申請を承認した場合を考えるL1<L2の場合。この場合、図33に例示するテーブルに示すように、仲間期間設定手段56は、レベル差Dが大きいほど、仲間期間を段階的に短く設定する。図33のテーブルの例では、レベル差Dが1~9のとき7日、10~29のとき6日、30~49のとき5日、50~69のとき4日、70~99のとき3日、100以上のとき2日に設定される。なお、仲間期間の日数はこれらに限定されるものではなく、レベル差Dが大きいほど仲間期間が短くなるという条件を満たせば、任意の期間を設定できる。このように、仲間申請した第1のプレイヤよりもレベルが高い第2のプレイヤが仲間申請を承認した場合は、承認した第2のプレイヤにとって、自分よりも下位レベルの第1のプレイヤとのレベル差Dが大きいほど、第1のプレイヤから受ける対戦協力等による貢献の程度は小さくなる。そこで、この場合には、レベル差Dが大きいほど仲間期間を短く設定することにより、より適切な仲間期間の設定を実現しているのである。次に、仲間申請した第1のプレイヤよりもレベルが低い第2のプレイヤが仲間申請を承認した場合を考えるL1>L2の場合。この場合、図33に例示するテーブルに示すように、仲間期間設定手段56は、レベル差Dが大きいほど、仲間期間を段階的に長く設定する。図33のテーブルの例では、レベル差Dが1~9のとき7日、10~29のとき8日、30~49のとき9日、50~69のとき10日、70~99のとき11日、100以上のとき12日に設定される。なお、仲間期間の日数はこれらに限定されるものではなく、レベル差Dが大きいほど仲間期間が長くなるという条件を満たせば、任意の期間を設定できる。このように、仲間申請した第1のプレイヤよりもレベルが低い第2のプレイヤが仲間申請を承認した場合は、承認した第2のプレイヤにとって、自分よりも上位レベルの第1のプレイヤとのレベル差Dが大きいほど、第1のプレイヤから受ける対戦協力等による貢献の程度は大きくなる。そこで、この場合には、レベル差Dが大きいほど仲間期間を長く設定することにより、より適切な仲間期間の設定を実現しているのである。また、仲間申請した第1のプレイヤとそれを承認した第2のプレイヤのレベルが同じ場合L1=L2の場合、図33に例示するように、仲間期間設定手段56は、仲間期間を7日に設定する。仲間期間設定手段56は、仲間関係が成立した2人のプレイヤに対して設定した仲間期間をデータベースサーバ2記憶装置に記憶する仲間期間記憶手段56aを備えている。図34に、仲間期間記憶手段56aが記憶する仲間期間の例を示している。仲間期間記憶手段56aは、仲間情報IDと対応づけて、仲間期間期間の長さおよび仲間期間終了予定時間等を記憶する。ここで、仲間期間終了予定時間とは、仲間期間の最終時刻にあたる現実世界の時間情報であり、年、月、日、時、分、秒等の時間が記憶される。ここで時間の単位は任意に設定できる。本実施の形態では、仲間期間記憶手段56aが、仲間期間終了予定時間として、仲間期間の最終時刻にあたる現実世界の日付年月日を記憶する例を示す。また、仲間期間記憶手段56aが、仲間情報IDと対応づけて、仲間期間が設定された日時や仲間関係が成立した日時等の時間情報を併せて記憶してもよい。次に、仲間関係解除手段57について説明する。仲間関係解除手段57は、仲間関係が成立している2人のプレイヤに対して設定された仲間期間の終了により、当該2人のプレイヤの仲間関係を自動的に解除する機能を有する。ここで、自動的に解除するとは、プレイヤによる自主的な解除操作がなくとも、ゲームサーバ1側で仲間関係の解除処理を実行することを意味する。仲間関係解除手段57は、データベースサーバ2に登録されている図8に示す仲間情報のうち、仲間関係が解除された仲間情報に該当する情報に解除フラグを付加したり当該情報を削除したりすることにより、仲間関係の解除処理を実行する。次に、仲間期間報知手段58について説明する。プレイヤは、端末装置3に表示される仲間リスト等の画面で、自分の仲間プレイヤとの間に設定されている仲間期間がいつまでなのかを確認できるようになっている。これを実現するために、仲間期間報知手段58は、仲間期間記憶手段56aに記憶されている仲間期間の情報を読み出し、プレイヤと仲間プレイヤとの間に設定されている仲間期間を表示させるための情報を、当該プレイヤの端末装置3へ送信し、プレイヤに仲間期間を報知する機能を有する。すなわち、仲間期間報知手段58は、仲間期間を含む画面データをプレイヤの端末装置3へ送信して、端末装置3の画面に仲間期間を表示させる制御を行う。仲間期間を含む画面の例としては、図35に示すような仲間リスト画面が挙げられる。仲間リスト画面には、リストアップされた各仲間との間に設定されている仲間期間を表示するための仲間期間表示領域80が設けられている。図35には、仲間期間表示領域80に、仲間期間の終了予定日1/17まで等が表示される画面例を示している。なお、仲間期間表示領域80に表示される仲間期間の情報は、仲間期間の終了予定日に限定されるものではなく、仲間期間の終了予定時間年、月、日、時、分、秒等の任意の単位の時間情報としてもよい。あるいは、例えば仲間期間の残日数あと10日間等や残時間あと20時間10分15秒等が仲間期間表示領域80に表示されるようにしてもよい。次に、図36ないし図38を参照して、ゲームサーバ1における仲間期間設定および仲間解除処理について説明する。図36ないし図38のフローチャートは、仲間関係が成立したある2人のプレイヤを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している全ての仲間同士のペアに対して同様の処理が行われることになる。図36に示すように、第1のプレイヤから仲間申請を受けた第2のプレイヤがそれを承認することによって、2人のプレイヤ間で仲間関係が成立した場合S251でYES、仲間期間設定手段56が、第1のプレイヤのレベルと第2のプレイヤのレベルとの関係を含む所定条件に基づいて仲間期間を決定するS252。このS252の仲間期間決定処理の一例を、図37に示す。図37中において、仲間申請をした第1のプレイヤのレベルをL1、それを承認した第2のプレイヤのレベルをL2として表している。仲間期間設定手段56は、L1<L2のときS261でYES、仲間期間を5日とするS262。また、仲間期間設定手段56は、L1>L2のときS261でNOおよびS263でYES、仲間期間を10日とするS264。また、仲間期間設定手段56は、L1=L2のときS61でNOおよびS63でNO、仲間期間を7日とするS265。図36のS52の仲間期間決定処理の他の例を、図38に示す。仲間期間設定手段56は、仲間申請をした第1のプレイヤのレベルL1と、それを承認した第2のプレイヤのレベルL2との差であるレベル差Dを算出するS271。そして、仲間期間設定手段56は、L1<L2のときS272でYES、レベル差Dが大きいほど仲間期間を短くするS273。例えば、図33に例示するテーブルを参照し、レベル差Dに応じた仲間期間L1<L2の場合を取得する。また、仲間期間設定手段56は、L1>L2のときS272でNOおよびS274でYES、レベル差Dが大きいほど仲間期間を長くするS275。例えば、図33に例示するテーブルを参照し、レベル差Dに応じた仲間期間L1>L2の場合を取得する。また、仲間期間設定手段56は、L1=L2のときS272でNOおよびS274でNO、仲間期間を7日とするS276。図36に戻って説明を続けると、仲間期間設定手段56は、上記のように仲間関係成立時に決定した仲間期間を、第1のプレイヤおよび第2のプレイヤに対して設定するS253。例えば、仲間期間設定手段56は、図34に示すように、仲間関係が成立している2人のプレイヤを関係付けた仲間情報と対応付けて、仲間期間を記憶する。その後、仲間関係が成立している2人のプレイヤに設定された仲間期間が終了した場合S254でYES、仲間関係解除手段57は、当該2人のプレイヤの仲間関係を自動的に解除するS255。例えば、仲間関係解除手段57は、データベースサーバ2に登録されている2人の仲間情報に解除フラグを付加することにより、仲間関係の解除処理を実行する。その後、ゲームサーバ1は、仲間関係が解除された2人のプレイヤの端末装置3に対して、仲間関係が解除された旨を報知するための情報解除の旨を含む画面データ等を送信し、当該2人のプレイヤに仲間関係が解除されたことを報知するS256。報知の例としては、ゲーム画面の中に仲間関係が解除された旨を表示することの他に、音声による報知や画面表示と音声とを併用した報知も考えられる。音声による報知は、ゲームサーバ1からプレイヤの端末装置3へ送信する画面データHTMLデータ等に音声データを含ませることにより実現できる。なお、ゲームサーバ1が、仲間関係が解除されたことを報知するためには、プレイヤの端末装置3がゲームサーバ1にアクセスしている必要がある。よって、ゲームサーバ1は、S255の仲間関係の解除処理を実行した後、仲間関係が解除された各プレイヤの端末装置3がゲームサーバ1に最初にアクセスしたときに、S256の報知処理を実行することになる。次に、仲間期間設定手段56が、仲間関係が成立した2人のプレイヤ間のレベル差に応じて仲間期間を設定する構成において、仲間期間中にレベル差が変動した場合に、変動後のレベル差に応じた仲間期間に再設定する構成について説明する。ここでは、図33に示すテーブルに基づいて、仲間期間設定手段56がプレイヤ間のレベル差に応じた仲間期間を設定する場合を例に挙げて説明する。図39に示すように、ゲームサーバ1は、レベル差記憶手段60を備えている。なお、図39に示すゲームサーバ1は、図4に記載の仲間履歴送信手段101および仲間復活申請手段102を具備しているが、図39中ではこれらの手段101102の記載を省略している。さらに、図39に示すゲームサーバ1は、図25に記載の復活時間記憶手段104、再復活制限手段105および復活回数記憶手段106を具備する構成であってもよい。レベル差記憶手段60は、仲間期間設定時再設定時を含むにおける、仲間申請した第1のプレイヤのレベルL1とそれを承認した第2のプレイヤのレベルL2との差であるレベル差を、データベースサーバ2記憶装置に記憶する機能を有する。例えば、図40Aに示すように、レベル差記憶手段60は、両プレイヤの仲間情報を一意に示す仲間情報IDと対応付けて、仲間期間設定時のプレイヤ間のレベル差を記憶するようになっている。この例では、レベル差をL1-L2として算出し、L1>L2のときのレベル差はプラスの値、L1<L2のときのレベル差はマイナスの値として管理できるようにしている。このレベル差記憶手段60は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。そして、仲間期間設定手段56は、仲間期間中のプレイヤ間のレベル差が、レベル差記憶手段60に記憶されている仲間期間設定時におけるレベル差から変動した場合に、変動後のレベル差に応じて仲間期間を再設定する機能を有する。この仲間期間の再設定処理について、図41のフローチャートを参照しながら以下に説明する。なお、既出のフローチャートにおいて示したステップと同様のステップについては同一のステップ番号を付し、詳細な説明を省略する以降のフローチャートにおいても同様である。仲間期間設定手段56が仲間関係成立時に2人のプレイヤに対して仲間期間を設定した場合S301でYES、レベル差記憶手段60が仲間期間設定時におけるプレイヤ間のレベル差を記憶するS302。その後、仲間期間設定手段56は、仲間期間中にS303でNO、少なくとも一方のプレイヤのレベルが変化することによりプレイヤ間のレベル差の変動を検出した場合S304でYES、変動後のレベル差に応じて仲間期間の再設定の必要性を判断するS305。すなわち、図33に示すテーブルに基づいて取得した変動後のレベル差に応じた仲間期間が、仲間期間設定時における仲間期間から変化しているか否かを判断する。具体例を挙げると、仲間成立時において、仲間申請したプレイヤのレベルL1が30であり、それを承認したプレイヤのレベルL2が57であったとする。よって、図40Aの仲間情報ID=20に示すように、プレイヤ間のレベル差-27=30-57に応じた仲間期間として6日が設定されたとする。その後、仲間期間中に、承認した側のプレイヤのレベルL2が1つ向上して58になり、プレイヤ間のレベル差が-28になっても、図33のテーブルに基づけば、L1<L2の場合、レベル差が10~29の範囲では仲間期間は6日のままであることから、仲間期間の再設定の必要性はないことになる。例えば、仲間期間中にレベル差が-30になった場合、図33のテーブルに基づけば、変動後のレベル差に応じた仲間期間は5日になり、仲間期間を再設定する必要性が生じる。仲間期間の再設定が必要である場合S305でYES、仲間期間設定手段56は、変動後のレベル差に応じた仲間期間を再設定するS306。例えば、図40Aに示す仲間情報ID=20の仲間期間および仲間期間終了予定時間を、図40Bに示す情報に更新する。すなわち、仲間期間設定手段56は、データベースサーバ2に記憶している仲間期間を、6日から5日に短縮し、それに伴って仲間期間終了予定時間も1日早くする11/1/10から11/1/9へ更新する。上記では、再設定された仲間期間が元の期間よりも短くなる例を示したが、当然、再設定された仲間期間が元の期間よりも長くなる場合もある。仲間期間の再設定が実行されたときは、S102に戻って、レベル差記憶手段60が再設定時におけるプレイヤ間のレベル差を記憶更新する。なお、仲間期間が終了した場合はS303でYES、仲間関係解除手段57により仲間関係が自動的に解除されS255、仲間関係が解除されたことが2人のプレイヤの端末装置3に報知されるS256。このように、プレイヤ間のレベル差に応じて適切な仲間期間を設定した後、その仲間期間中にプレイヤ間のレベル差が変動した場合、変動後のレベル差に応じた仲間期間に再設定することにより、仲間期間設定後のプレイヤ間のレベル差変動に追従した適切な仲間期間の調整を実現できる。なお、上記では、仲間期間設定手段56がプレイヤ間での仲間関係の成立時に、仲間期間を設定する構成について説明したが、これに限定されるものではなく、仲間期間設定手段56が仲間期間を設定するタイミングについては、任意に定めることができる。例えば、仲間期間設定手段56による仲間期間の設定タイミングは、プレイヤ間で仲間関係が成立してから一定期間経過後とすることができる。ここで、一定期間としては、例えば、3日、1週間、10日、2週間、1か月等、任意の期間を設定することができる。このように、仲間関係の成立直後の一定期間を猶予期間として、仲間期間が設定されることにより仲間関係が自動解除され得る状態には移行しないようにしてもよい。以上のように、本実施の形態では、2人のプレイヤ間での仲間関係の成立時に仲間期間を設定し、仲間期間の終了により、原則的に、当該2人のプレイヤの仲間関係を自動的に解除するようになっている。これにより、例えば、下位レベルのプレイヤからの仲間申請を承認して仲間になっても、仲間になった時点で仲間期間が設定されるので、プレイヤは、心理的にも行い難い仲間解除の操作をすることなく、仲間期間の終了により仲間関係の解除が可能となる。そして、プレイヤは、仲間関係の成立から仲間期間の終了までの間に、相手との交流の程度等から判断して仲間関係を継続すべきかどうかを判断することができる。そして、仲間関係を継続したいと思うような相手であれば、例えば、仲間期間終了後に改めて仲間申請を行う等の所定の操作をして仲間関係を継続すればよい。すなわち、仲間関係成立時に設定される仲間期間をお試し期間として捉えて、例えば自分より下位レベルのプレイヤから仲間申請を受けたような場合でも、これを積極的に承諾して試しに仲間になり、仲間期間終了までに自分が望むような交流等ができる相手かどうかを検討することも可能となる。また、各プレイヤが他のプレイヤと仲間関係を構築することができる仲間数に上限が設定されているゲームにおいて、プレイヤの仲間数が上限に達していた場合でも、仲間期間終了に伴う仲間関係の自動解除により、上限までに余裕ができる。すなわち、仲間数が一旦上限まで達したプレイヤであっても、従来のように実質的に仲間が固定された状態に陥ることはなく、他のプレイヤと新たな仲間関係を構築するための機会が与えられる。そして、プレイヤは、仲間期間中に交流が持てなかった下位レベルのプレイヤとは、自動解除された仲間関係を終え、再度、仲間申請や承認をしたりすることはないと考えられる。その一方、プレイヤが望むような相手上位レベルのプレイヤや楽しく交流が持てるようなプレイヤとは、仲間関係を継続するために、上述の仲間復活申請や承認等の操作をすることが考えられる。よって、本実施の形態の構成により、仲間関係成立による仲間期間設定と、仲間期間終了による仲間関係の自動解除と、必要に応じた仲間関係復活の申請とを繰り返しながら、プレイヤの好むような仲間グループの構成に収束されていく環境が整えられる。したがって、プレイヤが、あまり交流のない下位レベルの仲間プレイヤを何人も抱え、自分好みの仲間のグループ構成になっていない状態で実質的に仲間が固定されてしまうことへの不満を解消できる。特に、仲間数に上限が設定されているゲームの場合、従来では、比較的レベルの高いプレイヤが、あまり交流のない下位レベルの仲間を何人も抱えた状態で仲間数が上限まで達し、仲間が固定されてしまうことが多かった。これに対し、本ゲームサーバ1を適用した場合、仲間数に上限が設定されているゲームであっても、他のプレイヤと新たな仲間関係を構築し易すい環境がプレイヤに提供されるので、継続的に新たな仲間との交流を楽しめるようになる。よって、長期間にわたりゲームを継続しても、ゲームに対するマンネリ感が発生しにくい。ところで、仲間関係が解除されても、仲間関係の復活により、再度、仲間関係が成立した場合、改めて仲間期間設定手段56により仲間期間が設定されることになる。すなわち、仲間期間設定手段56は、仲間復活申請をしたプレイヤ第1のプレイヤおよび当該仲間復活申請を承認したプレイヤ第2のプレイヤの2人のプレイヤ間での仲間関係の成立時に、第1のプレイヤのゲームレベルと第2のプレイヤのゲームレベルとの関係を含む所定条件に基づいて仲間期間を決定し、当該2人のプレイヤに対して仲間期間を設定するのである。2人のプレイヤ間で上記のようにして仲間関係が復活した場合、初めて仲間関係が成立した場合よりも、当該2人のプレイヤは仲間関係の継続を望んでいる可能性が高い。そこで、仲間期間設定手段56は、申請した第1のプレイヤとそれを承認した第2のプレイヤとのレベル関係の条件が同じであれば、復活により仲間関係が成立した場合の仲間期間を、初めて仲間関係が成立した場合の仲間期間よりも長くすることが望ましい。例えば、2人のプレイヤのレベル関係に基づいて、初めて仲間関係が成立した場合の仲間期間が5日間に設定されるのであれば、同じレベル関係の条件で復活により仲間関係が成立した場合には、仲間期間が前記の2倍の10日間に設定されようにする。また、仲間期間設定手段56は、申請した第1のプレイヤとそれを承認した第2のプレイヤとのレベル関係の条件が同じであれば、仲間関係復活の回数が多い程、仲間期間をより長く設定することが望ましい。また、仲間関係の復活を何度も繰り返しているプレイヤ同士は、仲間関係が自動的に解除されることを望んでいない可能性が極めて高いと考えられる。そこで、仲間期間設定手段56は、所定回数以上例えば3回以上、仲間関係の復活が実行された2人のプレイヤについては、仲間期間を設定しないまたは、仲間期間を無制限とすることが望ましい。次に、仲間期間を自動延長することができるゲーム管理装置の構成例を、図39の機能ブロック図を参照しながら説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。本実施の形態のゲームサーバ1ゲーム管理装置は延長手段61を備えている。この延長手段61は、仲間期間が設定されている2人のプレイヤの少なくとも一方から相手のプレイヤに対して、仲間期間が終了するまでに所定回数または所定回数以上の交流処理が実行された場合に、当該仲間期間を延長する機能を有する。この延長手段61は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。仲間になったプレイヤ間で交流が持たれないということは、お互いに相手への関心が希薄であると考えられる。一方、仲間同士で交流を行っている場合には、プレイヤが仲間関係の維持を望んでいる可能性が高いと考えられる。そこで、仲間期間が終了するまでに条件を満たす交流があった場合に、仲間期間を自動的に延長し、仲間関係が継続されるようにするのである。そして、延長手段61は、仲間期間が延長された2人のプレイヤの少なくとも一方から相手のプレイヤに対して、延長された仲間期間が終了するまでに所定回数の交流処理が実行される毎に、仲間期間を延長することを繰り返すようになっている。これにより、条件を満たす交流を継続的に行っている仲間同士については、仲間期間の自動延長が繰り返されることにより仲間関係が継続して維持される。延長の対象となる交流については、前述の挨拶、メッセージの送信、プレゼント、協力対戦の助っ人依頼、合同練習など、仲間のプレイヤ同士で行われる様々な交流を含めることができる。また、挨拶は延長の対象とはせず、メッセージの送信、プレゼント、協力対戦の助っ人依頼、合同練習のみを延長の対象とするといったように、ゲーム内に用意された複数の交流から一部の交流のみを延長の対象としてもよい。また、2人のプレイヤの少なくとも一方から相手のプレイヤに対しての所定回数の交流があったことを、延長の条件とする。この条件を満たす形態には、いずれか一方から相手に対して所定回数の交流があれば条件を満たすとする形態と、両者とも互いに相手に対して所定回数の交流を行うことを条件とする形態とを含む。何れの形態を延長の条件として設定してもよい。特に、従来の課題であるところの、上位レベルのプレイヤにとって、仲間のプレイヤのレベルが自分よりも低い場合に、ゲームにおける協力対戦等について不公平感が生じていたということをより積極的に解消するために、少なくとも下位レベルのプレイヤが上位レベルのプレイヤに対して、所定回数またはそれ以上の交流を行うことを条件とすることが望ましい。また、仲間期間が終了するまでに所定回数の交流処理が実行されたことを延長の条件とすることに関し、所定回数として任意の回数を設定可能である。例えば、この所定回数を1回としてもよいし、2回以上の複数回としてもよい。また、相対的にゲームレベルが低いプレイヤから相手のプレイヤに対して交流処理が実行される場合の所定回数N1は、相対的にゲームレベルが高いプレイヤから相手のプレイヤに対して交流処理が実行される場合の所定回数N2よりも多い設定とすることが望ましい。一例としては、前記所定回数N1を3回とし、前記所定回数N2を2回とする。そして、いずれか一方から相手に対して前記所定回数の交流があれば延長条件を満たすものとする。または、両者とも互いに相手に対して前記所定回数の交流があれば延長条件を満たすものとする。この構成によれば、レベルの異なる2人のプレイヤが仲間になった場合、下位レベルのプレイヤは上位レベルのプレイヤとの仲間関係を維持するためには、上位レベルのプレイヤよりも多くの回数の交流を必要とする。よって、上位レベルのプレイヤは、下位レベルのプレイヤとの仲間関係を終了させ易くなることから、自分好みの仲間グループをより構築し易くなる。また、延長手段61が、プレイヤ間のレベル差に応じて延長の条件を満たすための交流の所定回数を設定する構成としてもよい。この場合、相対的にゲームレベルが低いプレイヤから相手のプレイヤに対して交流処理が実行される場合の所定回数N1を、両プレイヤ間のレベル差Dが大きいほど多い設定とすることが望ましい。一例としては、レベル差Dが29以下であれば所定回数N1を3回、レベル差Dが30~69であれば所定回数N1を4回、レベル差Dが70~99であれば所定回数N1を5回、レベル差Dが100以上であれば所定回数N1を6回とする。これにより、下位レベルのプレイヤは上位レベルのプレイヤとのレベル差が大きいほど、仲間関係を維持するために多くの回数の交流を必要とする。よって、上位レベルのプレイヤにとっては、レベルが離れた下位レベルのプレイヤほど仲間関係を終了させ易くなる。逆に、相対的にゲームレベルが高いプレイヤから相手のプレイヤに対して交流処理が実行される場合の所定回数N2を、両プレイヤ間のレベル差が大きいほど少ない設定としてもよい。一例としては、レベル差Dが29以下であれば所定回数N2を3回、レベル差Dが30~69であれば所定回数N2を2回、レベル差Dが70以上であれば所定回数N2を1回とする。これにより、上位レベルのプレイヤから下位レベルのプレイヤへ交流を行なうのであれば、レベル差が大きいほど少ない回数の交流で仲間関係を容易に維持できるようになる。上記のように、延長手段61がプレイヤ間のレベル差に応じて延長の条件を満たすための交流の所定回数を設定する構成において、延長手段61がプレイヤ間のレベル差の変動を検出したとき、変動後のレベル差に応じた所定回数に再設定するようにしてもよい。これにより、プレイヤ間のレベル差変動に追従して、延長の条件を満たすための交流の所定回数を適切に調整することができる。ここで、延長手段61が延長する期間の長さについては、一定の期間とすることができる。延長期間の長さを一定期間とする場合、例えば、1週間、10日間、2週間等、任意の期間を設定可能である。なお、延長の期間の長さは一定期間に限定されるものではない。例えば、延長が行われる毎にランダムに延長の期間を決定してもよい。また、交流回数によって延長の期間を変動させる交流回数が多いほど延長の期間を長く設定する構成であってもよい。あるいは、仲間期間設定手段56がプレイヤ間のレベル差に基づいて決定した仲間期間仲間期間記憶手段56aが記憶している仲間期間と同じ期間を、延長手段61が延長の期間として設定してもよい。あるいは、延長手段61が延長処理を実行するときのプレイヤ間のレベル差に基づいて、延長の期間を設定する構成にすることもできる。例えば、図33に例示したプレイヤ間のレベル差と仲間期間との関係を表すテーブルを、プレイヤ間のレベル差と延長の期間との関係を表すテーブルとして援用または共用し、延長処理実行時のプレイヤ間のレベル差に応じた延長の期間を、当該テーブルに基づいて取得するようにする。もちろん、プレイヤ間のレベル差と延長の期間との関係を表す専用のテーブルを別途用意して、ゲームサーバ1の記憶手段RAM13または補助記憶装置14等に記憶しておいてもよい。この構成の場合、延長処理が実行される毎に、その都度、延長処理実行時のプレイヤ間のレベル差に基づいた適切な延長の期間を設定することができる。また、延長手段61が延長処理実行時のプレイヤ間のレベル差に基づいて、延長の期間を設定する構成において、延長手段61がプレイヤ間のレベル差の変動を検出したとき、変動後のレベル差に応じた延長の期間に再設定するようにしてもよい。これにより、プレイヤ間のレベル差変動に追従して、延長の期間を適切に調整することができる。延長手段61による延長処理の実行は、データベースサーバ2に記憶されている仲間期間の情報を、延長後の情報に更新する等により行うことができる。例えば、延長手段61は、図42に示すように、仲間期間記憶手段56aが記憶仲間情報IDと対応づけて記憶している仲間期間終了予定時間を、延長後の日付に更新することにより、延長処理を実行する。このとき、仲間情報IDと対応づけて、延長処理実行時の時間情報として仲間期間を延長した日等を併せて記憶する。延長処理実行時の時間情報としては、年、月、日、時、分、秒等の時間情報を記憶するが、ここで記憶する時間の単位は任意に設定できる。また、延長された仲間期間の情報管理のために、仲間情報IDと対応づけて、延長フラグを設定するようにしてもよい。延長手段61による処理形態の1つとしては、仲間期間の途中で延長条件を満たす毎に、仲間期間の延長処理を実行する形態がある。この形態の延長処理について、図44を参照して、以下に説明する。なお、図44およびそれ以降のフローチャートは、仲間関係にある2人のプレイヤを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している全ての仲間同士のペアに対して同様の処理が行われることになる。図44に示すように、延長手段61は、2人のプレイヤに設定された仲間期間が終了する前にS281でNO、交流に関する延長条件が達成されたか否かを判定するS282。例えば、この判定は、図42に示す仲間期間の情報仲間期間終了予定時間等、および図43に示すプレイヤの交流履歴の情報に基づいて行うことができる。すなわち、データベースサーバ2には、各プレイヤの交流履歴が記憶されているので、仲間期間が設定されてから仲間期間が終了するまでにまたは、仲間期間が延長されてから延長された仲間期間が終了するまでに、延長条件として定められた所定回数の交流をプレイヤが行った状態を検出可能である。交流に関する延長条件が達成された場合S282でYES、延長手段61は、仲間期間の延長処理を実行するS283。例えば、図42に示す仲間期間終了予定時間を、延長後の日付に更新する。このとき、延長処理実行時の時間情報を記憶または更新する。ここで、具体的な延長例を挙げる。1月1日に設定された仲間期間が例えば7日間1月7日までであり、3日目の1月3日に交流の延長条件が達成された場合、1月3日の時点で例えば7日間の延長が発生し、仲間期間の終了日は1月7日現終了日から7日後の1月14日になる。よって、1月3日の時点での仲間期間の残期間残日数は11日間になる。例えば、その後、1月6日に交流の延長条件が再度達成された場合、1月6日の時点で7日間の追加延長が発生し、仲間期間の終了日は1月14日現終了日から7日後の1月21日になる。よって、1月6日の時点での仲間期間の残期間は17日間になる。この延長例の場合、交流に関する延長条件が連続して早期に達成されると、仲間期間の残期間は増加する傾向にある。例えば、短期間に多数の交流を行って仲間期間の残期間が急激に増加した場合を考えると、その後交流が長期間途絶えた場合でも、仲間関係が長期間維持されることになる。そこで、仲間期間の残期間に上限を設けてもよい。例えば、仲間期間の残期間の上限を30日に設定すれば、30日以上交流に関する延長条件が満たされなければ、仲間期間は終了してしまう。よって、仲間関係を維持するためには、最長30日の期間以内に交流に関する延長条件を満たすことが必要となり、長期間交流が途絶えているのに仲間関係が維持されることを回避できる。そこで、S283の後、延長手段61は、仲間期間の残期間が上限を超えている場合S284でYES、仲間期間の残期間を上限に制限するS285。すなわち、図42に示す仲間期間終了予定時間を、仲間期間の残期間の上限に合致する日付に更新する。延長後の仲間期間の残期間が上限を超えていない場合S284でNO、または仲間期間の残期間を上限に制限した後S285、S281に戻り、以降、仲間期間が終了するまでS281~S285の処理が繰り返される。ここで、他の具体的な延長例を挙げる。1月1日に設定された仲間期間が例えば7日間1月7日までであり、3日目の1月3日に交流の延長条件が達成された場合、1月3日の時点で例えば7日間の延長が発生するのであるが、仲間期間の終了日は1月3日延長発生日から7日後の1月10日になる。よって、1月3日の時点での仲間期間の残期間は7日になる。例えば、その後、1月6日に交流の延長条件が再度達成された場合、1月6日の時点で7日間の再延長が発生し、仲間期間の終了日は1月6日延長発生日から7日後の1月13日になる。よって、1月6日の時点での仲間期間の残期間は7日になる。この延長例では、仲間期間の残期間は最大でも延長期間この例では7日間となるので、仲間期間の残期間に上限を設ける必要はない。仲間期間の残期間に上限を設けない場合は、前記S84およびS85の処理を省くことができる。また、交流に関する延長条件を満たすことなく仲間期間が終了した場合S281でYES、仲間関係解除手段57により仲間関係が自動的に解除されS255、仲間関係が解除されたことが2人のプレイヤの端末装置3に報知されるS256。このS255およびS256の詳細は、図36において説明したとおりである。このように、仲間関係にある2人のプレイヤに対して設定された仲間期間は、交流に関する所定の延長条件を満たす毎に延長される。そして、前述の仲間期間報知手段58は、仲間期間延長された場合、延長後の仲間期間を表示させるための情報を、プレイヤの端末装置3へ送信し、プレイヤに仲間期間を報知する機能を有する。よって、各プレイヤは、図35に例示する仲間リスト画面で、自分の各仲間プレイヤとの間に設定されている仲間期間延長後の仲間期間がいつまでなのかを確認できるようになっている。そして、プレイヤは、仲間関係を終了させたくない仲間プレイヤについては、仲間リストで確認した仲間期間が終了するまでに延長条件を満たす交流を行うことにより、仲間関係を継続できる。このように、プレイヤの端末装置3に表示される仲間リスト画面に仲間期間延長後の仲間期間の情報を含めることにより、プレイヤ自身による仲間管理を容易にすることができる。延長手段61による処理形態としては、仲間期間の終了時刻に延長条件を満たしているか否かを判定し、延長条件を満たしている場合に仲間期間の延長処理を実行する形態もある。換言すれば、設定されている仲間期間の全期間の経過を待って延長の要否を判定し、延長処理を実行する形態である。この形態の延長処理について、図45を参照して、以下に説明する。延長手段61は、2人のプレイヤに設定された仲間期間の終了時刻になったときにS291でYES、交流に関する延長条件が達成されたか否かを判定するS292。このS292の処理は、前述のS282と同様の処理である。交流に関する延長条件を満たしている場合S292でYES、延長手段61は、仲間期間の延長処理を実行するS293。一方、交流に関する延長条件を満たしていない場合S293でYES、仲間期間の終了に伴い、仲間関係解除手段57により仲間関係が自動的に解除されS255、仲間関係が解除されたことが2人のプレイヤの端末装置3に報知されるS256。上記のように、本実施の形態の構成では、プレイヤが仲間復活申請や仲間継続申請のような特別な操作を行うことなく、ゲーム内で仲間同士が延長条件を満たす交流を楽しむだけで自動的に仲間期間が延長され、仲間関係を継続できるようになっている。特に、ソーシャルゲーム等のプレイヤの操作の容易化簡素化が強く求められるゲームサービスを提供する場合には、特別な操作を要することなく仲間関係を継続できる本構成が好適である。一方、延長条件を満たすような交流が行われなかった場合、お互いの関心が希薄であり、交流を楽しめるような仲間同士ではなかったということが考えられる。この場合、仲間期間が延長されることなく仲間期間の終了により仲間関係が自動的に解除されるので、やはり仲間解除のための特別な操作は不要である。また、本実施の形態では、仲間期間の延長の概念を、仲間との交流を楽しむというソーシャル要素を取り入れたゲームに導入したことにより、現実世界の仲間関係対人関係に近い関係を、ゲーム内で仮想的に実現できる。すなわち、現実世界では、仲間知り合いになってから継続的に交流が保たれていればその仲間関係は維持されるが、一旦仲間になっても、その後、あまり交流が持たれなかった場合には、両者が親密な関係を構築できないまま仲間関係は自然消滅する。そして、本実施の形態では、交流が持たれたときの仲間関係の維持を仲間期間の延長およびその繰り返しにより実現し、交流が持たれなかった場合の仲間関係の自然消滅を、仲間期間の延長がなされないまま仲間期間が終了することによる仲間関係の自動解消により実現している。一方、従来では、仲間関係を解除する操作が必要である等の理由により、全く交流がない又は殆ど交流がない仲間であっても、仲間として維持しているケースが殆どであり、現実世界の仲間関係とゲーム内の仲間関係とは大きく乖離しているのが現状である。本実施の形態の構成を適用したゲームでは、プレイヤが仲間と交流を持ちながら普通にゲームをプレイしてさえいれば、実際に交流を楽しんでいる仲間で構成された仲間グループが自然に構築されることになる。ところで、延長手段61による仲間期間の延長が何度も繰り返されているプレイヤ同士は、仲間関係が自動的に解除されることを望んでいない可能性が高いと考えられる。そこで、延長手段61は、仲間期間が終了するまでに所定回数または所定回数以上の交流があった場合に仲間期間を延長する延長処理に加え、仲間期間の延長処理自体が所定回数以上例えば3回以上実行された2人のプレイヤに対しては、仲間期間を無制限にする換言すれば、仲間期間を無期限に延長することが望ましい。但し、下位のプレイヤが上位のプレイヤに対して一方的に交流を行った結果として仲間期間の延長処理が所定回数以上実行された場合までを含めて、仲間期間を無制限にすると、上位プレイヤから不満が出る可能性もある。そこで、この場合、2人のプレイヤの両方とも互いに相手に対して所定回数または所定回数以上の交流を行うことを延長の条件とすることが望ましい。両方とも互いに相手に対して所定回数以上の交流があった場合に仲間期間の延長処理が実行され、この延長処理が所定回数以上繰り返されるということは、お互いに継続的に仲間関係を維持したいと考えていることが想定されるためである。なお、2人のプレイヤの仲間期間を無制限にするということは、仲間関係が自動的に解除されることがない状態にするという観点から、2人のプレイヤに仲間期間を設けないことと実質的に同じである。よって、2人のプレイヤの仲間期間を無制限にすることには、2人のプレイヤの仲間期間の設定を解除することも含まれる。次に、仲間関係が成立している2人に親密度というパラメータを設定し、親密度の値に応じて延長時の仲間期間を調整する構成について説明する。親密度とは、仲間関係が成立している2人のプレイヤの親密さを示すものであり、2人の友好度合い、友情の深さ、絆の深さ等として表現することもできる。図39に示すように、ゲームサーバ1は、親密度付与手段62および補正手段63を備えている。これらの手段62および63は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。親密度付与手段62は、交流手段55により仲間関係が成立している2人のプレイヤ間で交流処理が実行された場合に、当該2人のプレイヤに対して親密度を付与する機能を有する。本実施の形態の親密度付与手段62は、2人のプレイヤ間で交流処理が実行される毎に、所定値例えば1ポイントの親密度を付与するようになっている。なお、交流の内容により付与する親密度の値を変えてもよい。例えば、挨拶は1ポイント、メッセージ送信は2ポイント、プレゼントおよび対戦協力は3ポイント等としてもよい。また、本実施の形態では、2人の親密度の値に応じて、例えば5段階のランクが設けられている。例えば、親密度が0~24ポイントで知り合いランク、25~49ポイントで友人ランク、50~74ポイントで親友ランク、75~99ポイントで相棒ランク、100ポイント以上で盟友ランクとなる。親密度付与手段62は、親密度記憶手段62aを備えている。この親密度記憶手段62aは、例えば図46に示すように、仲間情報を一意に識別する仲間情報IDと対応づけて、2人のプレイヤに付与された親密度の値データベースサーバ2に記憶している。また、親密度のランクも併せて記憶していてもよい。仲間同士の2人のプレイヤが交流を重ねた結果として、2人の親密度の値が高くなることから、親密度の値が高いほど、お互いに仲間関係の維持を望んでいると考えられる。そこで、親密度の値が高いほど、延長処理における仲間期間を長く設定することにより、親密度に応じた適切な仲間期間を設定することができる。そこで、補正手段63は、2人のプレイヤの親密度の値が高いほど、延長手段61により延長される仲間期間延長期間が長くなるように補正する機能を有する。一例を挙げると、2人のプレイヤの親密度の値が知り合いランクのときに延長される仲間期間の長さをn日とした場合、友人ランクではn×1.5、親友ランクではn×2.0、相棒ランクではn×2.5、盟友ランクではn×3.0の期間補正を行う。また、補正手段63は、2人のプレイヤの親密度の値が閾値以上の場合例えば、100ポイント以上の盟友ランクに達している場合、仲間期間を無期限に設定すなわち仲間期間をなくすようにしてもよい。これは、2人のプレイヤの親密度の値が閾値以上まで高まった場合には、もはや何れのプレイヤも仲間関係の解除を望んでいない可能性が極めて高いと考えられるからである。この親密度の値に応じて延長時の仲間期間を補正する処理について、図47を参照して以下に説明する。2人のプレイヤに設定された仲間期間が終了する前にS281でNO、交流に関する延長条件が達成された場合S282でYES、2人のプレイヤの親密度の値が閾値以上か否かが判定されるS311。ここで、親密度の値が閾値以上の場合S311でYES、補正手段63は、仲間期間を無期限に設定するS312。また、親密度の値が閾値未満の場合S311でNO、補正手段63は、親密度の値に応じて延長手段61により延長される仲間期間延長期間を補正するS313。すなわち、補正手段63は、親密度の値が高いほど、延長期間が長くなるように補正する。S313の後、延長手段61は、補正手段63により補正された延長期間により仲間期間を延長するS314。また、S314の後は前記S81に戻り、仲間期間が終了するか又は親密度が閾値以上になるまでループ処理S281、S282、S311~S314を繰り返す。なお、仲間期間が終了した場合はS281でYES、仲間関係解除手段57により仲間関係が自動的に解除されS255、仲間関係が解除されたことが2人のプレイヤの端末装置3に報知されるS256。他の実施の形態特に上述のように仲間関係が自動解除される構成では、プレイヤの過去の仲間プレイヤが累積的に増加し易い。そこで、仲間関係が解除された時間条件を指定して過去の仲間プレイヤを抽出して表示できるようにする構成について説明する。仲間情報記憶手段54aは、仲間関係が解除された2人のプレイヤを関係付けた過去の仲間情報とともに、当該2人のプレイヤの仲間関係が解除された時間情報も記憶装置データベースサーバ2に記憶する。例えば図11Aまたは図11Bに例示するように、仲間情報記憶手段54aは、仲間情報IDまたは過去の仲間情報IDと対応づけて、仲間解除時間仲間関係が解除された日付等を記憶する。そして、前記仲間履歴送信手段101は、プレイヤが操作する端末装置3からの仲間関係が解除された時間の条件を指定した要求に応じて、仲間情報記憶手段54aに記憶されている当該プレイヤの過去の仲間情報のうち前記条件を満たす情報を読み出し、当該プレイヤの過去の仲間プレイヤであって前記条件を満たす過去の仲間プレイヤを表示させるための情報を当該端末装置3へ送信する。この構成により、プレイヤは過去の仲間リストを要求する操作を行う場合に、仲間関係が解除された時間条件を指定すれば、例えば1か月以内に仲間関係が解除された過去の仲間プレイヤのみを端末装置3に表示させたり、XX年XX月に仲間関係が解除された過去の仲間プレイヤのみを表示させたり等が可能となる。このように、仲間関係が解除された時間条件により絞り込み表示ができれば、特に過去の仲間が多くなった場合の操作性が向上する。次に、累積増加する過去の仲間情報を保持するための記憶容量を削減するための構成について説明する。仲間情報記憶手段54aは、2人のプレイヤの仲間関係が解除されてから少なくとも所定期間例えば1年間、当該2人のプレイヤを関係付けた過去の仲間情報を保持する。そして、仲間履歴送信手段101は、プレイヤが操作する端末装置3からの要求に応じて、仲間情報記憶手段54aに記憶されている当該プレイヤの過去の仲間情報のうち仲間関係解除後に前記所定期間例えば1年間を経過していない過去の仲間プレイヤの情報を読み出して当該端末装置3へ送信する。これにより、仲間関係の解除後における過去の仲間関係の情報の保持期間を、所定期間例えば1年間に限定することができる。プレイヤにとって、過去の仲間プレイヤとの仲間関係が解除されてから所定期間、例えば、1年間が経過してから、当該過去の仲間プレイヤと再度仲間関係を構築しようと考えることは、あまり無いと考えられる。そこで、仲間関係解除後、所定期間を経過していない過去の仲間プレイヤだけをプレイヤの端末装置3に表示させるようにすれば、仲間関係の解除後における過去の仲間情報の保持期間を、所定期間に限定することができる。これにより、累積増加する過去の仲間情報を保持するための記憶容量を大幅に削減することができる。また、上述の実施の形態では、ゲーム実行プログラムがゲームサーバ1側に実装されており、各プレイヤの端末装置3における入力操作に応じて、ゲームサーバ1がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置3へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明した。これはいわゆるクライアントサーバ型のゲームシステムであるが、これに限定されるものではない。例えば、ゲームサーバ1が、プレイヤの仲間情報を含むゲーム情報を管理し、ゲーム内での仲間管理等のゲームサービスをプレイヤに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはプレイヤの端末装置側にて行われるゲームシステムにも本発明の実施の形態に係るゲーム管理装置、ゲーム管理方法及びプログラムを適用できる。すなわち、ゲーム実行プログラムの一部または全部をプレイヤの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも適用できる。例えば、プレイヤの端末装置が、インターネット通信、無線LAN通信、所定の周波数帯例えば2.4GHzの周波数帯を用いた近距離無線通信、または有線LAN通信などにより他のプレイヤの端末装置とピアツーピア接続し、ピアツーピア型のゲームを実行することも可能である。よって、プレイヤの端末装置としては、ゲームサーバゲーム管理装置に接続して仲間管理等のゲームサービスの提供を受けることができる様々なものが適用でき、前述の携帯電話端末、スマートフォン、PHS端末、携帯情報端末PDA、パーソナルコンピュータ、タブレット型コンピュータ以外にも、ネットワーク接続機能を有している家庭用ビデオゲーム装置家庭用ビデオゲーム機を家庭用テレビジョンに接続することによって構成されるゲーム装置や、携帯型のゲーム専用装置なども適用可能である。また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスクCD-ROM、DVD-ROM等、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてゲームサーバ1のCPU11により実行される。また、プログラムをゲームサーバ1に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。