JP5124044B1 - ゲーム管理装置、ゲーム管理方法及びプログラム - Google Patents

ゲーム管理装置、ゲーム管理方法及びプログラム Download PDF

Info

Publication number
JP5124044B1
JP5124044B1 JP2011289991A JP2011289991A JP5124044B1 JP 5124044 B1 JP5124044 B1 JP 5124044B1 JP 2011289991 A JP2011289991 A JP 2011289991A JP 2011289991 A JP2011289991 A JP 2011289991A JP 5124044 B1 JP5124044 B1 JP 5124044B1
Authority
JP
Japan
Prior art keywords
player
fellow
information
game
friend
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2011289991A
Other languages
English (en)
Other versions
JP2013138729A (ja
Inventor
正能 鈴木
暢也 北村
浩之 冨田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Konami Digital Entertainment Co Ltd
Original Assignee
Konami Digital Entertainment Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Konami Digital Entertainment Co Ltd filed Critical Konami Digital Entertainment Co Ltd
Priority to JP2011289991A priority Critical patent/JP5124044B1/ja
Priority to PCT/JP2012/068400 priority patent/WO2013099336A1/ja
Application granted granted Critical
Publication of JP5124044B1 publication Critical patent/JP5124044B1/ja
Publication of JP2013138729A publication Critical patent/JP2013138729A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/795—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for finding other players; for building a team; for providing a buddy list
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/80—Special adaptations for executing a specific game genre or game mode
    • A63F13/847—Cooperative playing, e.g. requiring coordinated actions from several players to achieve a common goal
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/85—Providing additional services to players
    • A63F13/87—Communicating with other players during game play, e.g. by e-mail or chat
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/71—Game security or game management aspects using secure communication between game devices and game servers, e.g. by encrypting game data or authenticating players
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/75—Enforcing rules, e.g. detecting foul play or generating lists of cheating players
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/80—Special adaptations for executing a specific game genre or game mode
    • A63F13/828—Managing virtual sport teams
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/5546—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • A63F2300/556—Player lists, e.g. online players, buddy list, black list

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】仲間関係が解消された過去の仲間プレイヤと仲間関係を再構築するための機会が持てるゲーム環境をプレイヤに提供する。
【解決手段】ゲーム管理装置は、２人の仲間関係が解除された後も、当該２人のプレイヤを関係付けた過去の仲間情報を保持する仲間情報記憶手段５４ａと、プレイヤが操作する端末装置からの要求に応じて、当該プレイヤの過去の仲間リストを当該端末装置へ送信する仲間履歴送信手段１０１と、過去の仲間リストを表示している端末装置にて過去の仲間プレイヤを選択する操作が行われた場合に、当該操作の情報を端末装置から受信して当該プレイヤから当該過去の仲間プレイヤへの仲間関係復活の申請処理を実行する仲間復活申請手段１０２とを備える。
【選択図】図４

Description

本発明は、各プレイヤのゲーム情報を管理するゲーム管理装置、ゲーム管理方法及びプログラムに関するものである。
従来から、インターネット上に設置されたゲームサーバに、プレイヤの端末装置（パーソナルコンピュータ、携帯電話端末等）を接続することによって、プレイヤがゲームサーバから提供される各種ゲームサービスを受けることができるゲームシステムがある。
また、インターネットを介して共通のゲームをプレイするプレイヤ同士が、仲間関係を構築することができるゲームシステムも提案されている（特許文献１参照）。
そして近年、人と人とのつながりを促進・サポートするコミュニティ型のサービスであるソーシャルネットワーキングサービス（ＳＮＳ）のシステムに、前記ゲームシステムが組み込まれ、ＳＮＳのサービスの一つとして提供される、いわゆるソーシャルゲームが普及している。このようなソーシャルゲームにおいては、各プレイヤがゲームサービスを利用している他のプレイヤと仲間になり、仲間のプレイヤとコミュニケーションをとったり、協力して対戦したりすることで、プレイヤ同士が交流を行うことができるようになっている。そして、各プレイヤは、複数の他のプレイヤと仲間になって、これらの仲間と交流を持ちながらゲームを楽しむことができるようになっている。
特開２００３−４７７７８号公報
ところで、プレイヤ間の仲間関係は、何れか一方のプレイヤが仲間の解除操作を行うことにより、解消することができるようになっている。そして、従来のゲームシステムにおいては、一旦解除された仲間関係を再構築するためのシステムはなかった。
従来のゲームシステムにおいて、プレイヤが過去の仲間プレイヤと、再度、仲間関係を構築するには、仲間候補として過去の仲間プレイヤを見つけ出して仲間申請をする必要がある。しかし、プレイヤが過去の仲間プレイヤを見つけ出すことは、次に示すように決して容易ではない。すなわち、通常、プレイヤが仲間申請を行う相手は、ゲームサーバから提示される仲間候補リストの中から見つけて選択するのであるが、ゲームサーバは仲間候補をゲームサービス登録者の中からランダムに抽出している。よって、多数の（例えば数万人の）ゲームサービス登録者の中から過去の仲間プレイヤが仲間候補として抽出される確率は決して高くない。このように、従来では、一度、仲間関係が解除されてしまえば、過去の仲間プレイヤと仲間関係を再構築することは困難であった。
本発明は、上記の問題に鑑みてなされたものであり、その目的は、過去の仲間プレイヤと仲間関係を再構築するための機会が持てるゲーム環境をプレイヤに提供するゲーム管理装置、ゲーム管理方法及びプログラムを実現することである。
（１）本発明の一局面によるゲーム管理装置は、各プレイヤの端末装置と通信し、プレイヤ同士が仲間関係を構築することができるゲームの仲間管理を行うゲーム管理装置であって、仲間関係成立中の２人のプレイヤを関係付けた仲間情報を記憶するとともに、当該２人の仲間関係が解除された後も、当該２人のプレイヤを関係付けた過去の仲間情報を保持する仲間情報記憶手段と、プレイヤが操作する端末装置からの要求に応じて、前記仲間情報記憶手段に記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する仲間履歴送信手段と、前記仲間履歴送信手段が送信した情報を受信して前記プレイヤの過去の仲間プレイヤを表示している前記端末装置にて当該過去の仲間プレイヤを選択する操作が行われた場合に、当該操作の情報を前記端末装置から受信して当該プレイヤから当該過去の仲間プレイヤへの仲間関係復活の申請処理を実行する仲間復活申請手段と、を備える構成である。
この構成のゲーム管理装置は、各プレイヤの端末装置と通信を行うことができる、例えばサーバなどの情報処理装置により構成することができる。そして、本ゲーム管理装置は、プレイヤ同士が仲間関係を構築することができるゲーム、例えばプレイヤ同士が仲間になって交流を楽しむことができるソーシャルゲーム等のゲームの仲間管理を行う。
ここで、仲間関係とは、ゲーム内で構築されるプレイヤ同士の仮想的な関係の総称であり、知人、友人、友達、クラスメイト、相棒、親類、家族、兄弟、姉妹、会社や組織の同僚などの様々なゲーム内の関係を含む。
また、本ゲーム管理装置は、仲間関係成立中の２人のプレイヤを関係付けた仲間情報を記憶する仲間情報記憶手段を備えている。この仲間情報記憶手段は、２人の仲間関係が解除された後も、当該２人のプレイヤを関係付けた過去の仲間情報を保持する。
また、本ゲーム管理装置は、仲間履歴送信手段を備えている。この仲間履歴送信手段は、プレイヤが操作する端末装置からの要求に応じて、仲間情報記憶手段に記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する。この仲間履歴送信手段が送信した情報を受信したプレイヤの端末装置では、当該プレイヤの過去の仲間プレイヤを表示することができる。よって、プレイヤは、自分の過去の仲間履歴を、端末装置の表示画面上で容易に確認することができる。すなわち、プレイヤは、自分の過去の仲間プレイヤを確実且つ容易に特定できる。
そして、プレイヤにより、過去の仲間プレイヤを表示している端末装置にて、過去の仲間プレイヤを選択する操作が行われた場合には、仲間復活申請手段が当該操作の情報を受信して、当該プレイヤから当該過去の仲間プレイヤへの仲間関係復活の申請処理を実行する。すなわち、プレイヤは、端末装置に表示されている過去の仲間プレイヤを確認して、仲間関係を復活させたい所望の相手を選択する操作をすることで、その相手に対する仲間関係復活の申請を容易に行うことができる。
なお、プレイヤから仲間関係復活の申請を受けた相手（当該プレイヤの過去の仲間プレイヤ）、がそれを承認すれば、両者の仲間関係が復活することは言うまでもない。
以上のように、本構成により、プレイヤの端末装置に過去の仲間プレイヤを表示させて所望の相手に対して簡単に仲間関係復活の申請を行えるようにするという従来にはない斬新な機能をプレイヤに提供できる。これにより、過去の仲間プレイヤと仲間関係を再構築するための機会が持てるゲーム環境をプレイヤに提供できる。よって、例えば、従来ではなし得なかった下記（ａ）〜（ｃ）のようなことも可能になる。
（ａ）プレイヤが、仲間であった相手との仲間関係を誤操作等により誤って解除してしまった場合、その後、同じ相手と仲間関係を再構築する機会が得られる。
（ｂ）何らかの理由（例えば、海外出張や受験に専念等）でプレイヤが一時的に暫くゲームから離れる必要が生じた場合、その間、仲間プレイヤとの仲間関係を解消し、その後、ゲームを再開するときに、過去の仲間プレイヤに仲間関係復活の申請を行う。
（ｃ）各プレイヤが他のプレイヤと仲間関係を構築することができる仲間数に上限が設定されているゲームにおいて、次のようなことが可能になる。すなわち、仲間数が上限に達しているプレイヤが、新しい他のプレイヤＹと仲間になるために、仲間プレイヤＸとの関係を一旦解除する。その後、プレイヤＹと思うような交流ができなかったような場合には、プレイヤＹとの関係を解除した上で、プレイヤＸに仲間関係復活の申請を行う。このように、限られた仲間枠を有効に使った新たなゲームの楽しみ方ができる。
（２）上記の構成において、前記仲間情報記憶手段は、仲間関係にある２人のプレイヤの一方が仲間関係を自主的に解除した場合、当該２人のプレイヤのうち仲間関係を自主的に解除した側のプレイヤと、相手から仲間関係を自主的に解除された側のプレイヤと、を区別して記憶しており、前記仲間履歴送信手段は、プレイヤが操作する端末装置からの要求に応じて、前記仲間情報記憶手段に記憶されている当該プレイヤの過去の仲間情報のうち当該プレイヤが仲間関係を自主的に解除した場合の情報を読み出し、当該プレイヤが仲間関係を自主的に解除した過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信することが好ましい。
この構成によれば、仲間情報記憶手段が２人のプレイヤを関係付けた過去の仲間情報を記憶するにあたり、仲間関係を自主的に解除した側と解除された側とを区別して記憶している。そして、仲間履歴送信手段は、プレイヤが操作する端末装置からの要求に応じて、当該プレイヤが仲間関係を自主的に解除した過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する。よって、仲間履歴送信手段が送信した情報を受信したプレイヤの端末装置には、当該プレイヤが自ら仲間関係を解除した過去の仲間プレイヤのみが表示され、当該プレイヤが相手から仲間関係を解除された場合の相手情報は表示されないようにすることができる。
本構成により、仲間関係を解除された側のプレイヤが、解除した側のプレイヤに対して、仲間復活申請をすることがなくなる。これにより、仲間関係を自主的に解除した側のプレイヤが、折角解除した仲間プレイヤから、後日、望まないかたちで仲間関係復活の申請を受けるといった事態を効果的に回避できる。
また、相手から仲間関係を解除された側のプレイヤにとっても、自分を解除した相手に対して復活申請をしようと思わないことが多いと考えられる。よって、プレイヤにとっては、自分を解除した相手が省かれた状態で過去の仲間プレイヤが表示されることにより、所望の相手を見つけ易くなるという効果も期待できる。
（３）上記の（１）または（２）の構成において、ゲーム管理装置は、仲間申請をしたプレイヤおよび当該申請を承認したプレイヤの２人のプレイヤ間で仲間関係が成立したときに、少なくとも承認した側のプレイヤに対して仲間成立ポイントを付与する仲間成立ポイント付与手段をさらに備えていることが好ましい。そして、前記仲間成立ポイント付与手段は、前記仲間復活申請手段が実行した前記仲間関係復活の申請処理による仲間申請を承認した前記過去の仲間プレイヤに対して付与する前記仲間成立ポイントを、前記仲間関係復活の申請処理によらない通常の仲間申請を承認したプレイヤに対して付与する前記仲間成立ポイントよりも高くすることが好ましい。
この構成によれば、仲間申請側および承認側の両プレイヤ間で仲間関係が成立したときに、仲間成立ポイント付与手段が、少なくとも承認側のプレイヤに対して仲間成立ポイントを付与する。これは、仲間申請側および承認側の両方のプレイヤにそれぞれ仲間成立ポイントを付与する形態と、承認側のプレイヤのみに仲間成立ポイントを付与する形態とを含む。
そして、仲間成立ポイント付与手段は、仲間関係復活の申請処理による仲間申請を承認した過去の仲間プレイヤに対して付与するポイントを、通常の仲間申請を承認したプレイヤに対して付与するポイントよりも高くする。これにより、仲間関係復活の申請を受けたプレイヤの承認を促進し、仲間関係が復活され易いようにすることで、仲間関係を復活させる機能の実効性を高めることができる。
（４）上記の（３）の構成において、ゲーム管理装置は、前記仲間復活申請手段が実行した前記仲間関係復活の申請処理による仲間申請を前記プレイヤの過去の仲間プレイヤが承認して当該２人のプレイヤ間で仲間関係が復活した場合、当該２人のプレイヤの仲間関係の復活時間の情報を記憶する復活時間記憶手段と、前記復活時間記憶手段に記憶されている前記２人のプレイヤの復活時間から所定期間が経過するまでは、当該２人のプレイヤ間での仲間関係の再度の復活を許可しない再復活制限手段と、をさらに備えていることが好ましい。
前述のように、仲間関係復活の申請を承認した方が、通常の仲間申請を承認するより多くのポイントが得られるようにした場合、仲間同士でポイントの獲得だけを狙って仲間関係の解消と復活とを短期間で繰り返すという不適正な事態が生じる可能性がある。本構成は、このような事態を回避するため、復活時間記憶手段がプレイヤ間で仲間関係が復活したときの復活時間を記憶しておき、再復活制限手段が、復活時間から所定期間が経過するまでは仲間関係の再度の復活を許可しないように構成している。
ここで、復活時間記憶手段は「復活時間」として、年、月、日、時、分、秒等の時間情報を記憶するが、ここで記憶する時間の単位は任意に設定できる。また、仲間関係の復活後に再復活が禁止される期間である前記の「所定期間」としては、任意の期間を設定可能である。例えば、所定期間を一定の期間（例えば３か月等）としてもよいし、仲間関係の復活回数に応じて所定期間を変動させる（復活回数が多いほど所定期間を長く設定する）ようにしてもよい。
本構成により、２人のプレイヤが仲間関係の解除と復活とを繰り返すことによる不適正なポイント狙いを画策しても、一度仲間関係を復活させた後は、所定期間（例えば３か月）が経過するまで再度の復活ができなくなる。よって、仲間同士でポイントの獲得だけを狙って仲間関係の解消と復活とを短期間で繰り返すという不適正なプレイヤの行動を、効果的に抑制することができる。
（５）上記の（３）の構成において、ゲーム管理装置は、前記仲間復活申請手段が実行した前記仲間関係復活の申請処理による仲間申請を前記プレイヤの過去の仲間プレイヤが承認して当該２人のプレイヤ間で仲間関係が復活した場合、当該２人のプレイヤの仲間関係の復活時間の情報を記憶する復活時間記憶手段をさらに備えていることが好ましい。そして、前記仲間履歴送信手段は、前記復活時間記憶手段に記憶されている前記２人のプレイヤの復活時間から所定期間が経過するまでは、当該２人のプレイヤの仲間関係が再度解除された場合であっても、当該２人のプレイヤのうちの一方のプレイヤが操作する端末装置からの要求に応じて過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信するときに、送信する情報の中に他方のプレイヤの情報を含めないことが好ましい。
この構成によれば、復活時間記憶手段が２人のプレイヤ間で仲間関係が復活したときの復活時間を記憶しておき、仲間履歴送信手段が、復活時間から所定期間が経過するまでは、当該２人のプレイヤのうちの一方の端末装置へ送信する、過去の仲間プレイヤを表示させるための情報中に、他方のプレイヤの情報を含めないように構成している。これにより、２人のプレイヤが仲間関係の解消と復活とを繰り返すことによる不適正なポイント狙いを画策しても、一度仲間関係を復活させた後は、所定期間（例えば３か月）が経過するまで、お互い相手のプレイヤが過去の仲間プレイヤとして端末装置に表示されないので、仲間関係復活の申請ができなくなる。よって、仲間同士でポイントの獲得だけを狙って仲間関係の解消と復活とを短期間で繰り返すという不適正なプレイヤの行動を、効果的に抑制することができる。
（６）上記の（１）の構成において、ゲーム管理装置は、仲間関係が成立している２人のプレイヤに対して、プレイヤ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段と、仲間関係が成立している２人のプレイヤに対して設定された前記仲間期間の終了により、当該２人のプレイヤの仲間関係を自動的に解除する仲間関係解除手段と、をさらに備えていることが好ましい。
この構成によれば、次に説明するように、自分好みの仲間グループを構築し易い環境をプレイヤに提供することができる。すなわち、比較的高いレベルのプレイヤは、自分と同レベルまたは自分より高いレベルの他のプレイヤと仲間になることを希望する傾向にある。但し、プレイヤは、自分よりも低いレベルの他のプレイヤから仲間申請を受けた場合に、無碍にその申請を断りづらいこともあり、その申請を承認して仲間になるケースがある。しかし、高いレベルのプレイヤにとって、自分よりも低いレベルの仲間が多くなると、ゲームにおける協力対戦等について不公平感が生じてしまうこともある。その理由は、高いレベルのプレイヤにとっては、他のプレイヤに対して協力対戦等における貢献度が大きいのに対して、同様の貢献を低いレベルのプレイヤからは受けられないためである。
具体的には、ソーシャルゲームにおいては、プレイヤが他のプレイヤと対戦する場合に、自分の仲間に協力を求めることができる（協力対戦と呼称されることがある）。そして協力を求める対象の仲間のレベルが高いほど、対戦が有利になるのである。逆に、仲間のレベルが低いと、有利になる度合いも低いものとなる。従って、概ね、レベルの高いプレイヤは、レベルの低いプレイヤから協力を求められることが多くなり、他のプレイヤに貢献するケースが多くなる一方で、仲間内に自分よりレベルの高いプレイヤがいない場合には、同様のメリットを自分は享受できないという不満が生じることになる。
このため、高いレベルのプレイヤとしては、できれば、自分よりレベルの低い下位のプレイヤとの仲間関係を解消して、自分の好みの仲間のグループ構成としたいという希望を持つことがある。また、プレイヤより下位レベルの仲間プレイヤであっても、ゲーム内で楽しく交流ができるような仲間プレイヤであればよいが、仲間になってからあまり交流もなく、一緒にゲームを楽しめないような下位レベルの仲間プレイヤに対しては、仲間関係の解消をプレイヤが望むことが多い。しかし、そのためには、プレイヤが今まで仲間であった他のプレイヤ（自分より低いレベルの仲間）との関係を切る操作が必要であるが、心理的に行い難いと思うプレイヤも多い。
そこで、本ゲーム管理装置は、仲間関係が成立している２人のプレイヤに対して、プレイヤ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段を備えている。ここで、仲間期間設定手段が設定する仲間期間の長さとしては、例えば１週間、１０日、２週間、１ヶ月など、任意の期間長さに設定可能である。また、仲間期間の長さは固定であってもよいし、例えば設定時にランダムに期間長さを変えてもよいし、プレイヤ間のレベル関係に応じて適切な期間長さを決定するようにしてもよい。
また、仲間期間設定手段が仲間期間を設定するタイミングについても、任意に定めることができる。例えば、仲間期間の設定タイミングは、仲間関係の成立時であってもよいし、仲間関係が成立してから一定期間（例えば１週間）経過後であってもよいし、例えば２人のプレイヤ間で所定期間、交流が行われなかった状態が発生したときであってもよい。
そして、仲間関係解除手段は、仲間関係が成立している２人のプレイヤに対して設定された仲間期間の終了により、当該２人のプレイヤの仲間関係を自動的に解除するようになっている。よって、プレイヤは、心理的にも行い難い仲間解除の操作を行うことなく、仲間期間の終了により仲間関係の解除が可能となる。したがって、プレイヤは、例えば仲間になってから殆ど交流等もなく一緒にゲームを楽しめないような下位レベルの仲間に対しては、仲間期間の終了により仲間関係を断ち、改めて、自分の好みの新たな仲間を探すことができる。そして、プレイヤが仲間関係を継続したいと思うような相手であれば、仲間期間終了後に改めて同じ相手に、上述の仲間関係復活の申請を行えばよい。
このように、プレイヤは、一緒にゲームを楽しめなかった下位レベルの仲間とは、仲間期間の終了により仲間関係を終え、仲間関係復活の申請をしたりすることはないと考えられる。その一方、プレイヤが望むような相手（例えば、上位レベルのプレイヤや下位レベルであっても交流等により一緒にゲームを楽しめるようなプレイヤ）とは、仲間関係を継続するために、仲間関係復活の申請をすることが考えられる。よって、本構成により、仲間関係成立による仲間期間設定と、仲間期間終了による仲間関係の自動解除と、必要に応じた仲間関係復活の申請とを繰り返しながら、プレイヤの好むような仲間グループの構成に収束されていく環境が整えられるのである。
本構成のように、プレイヤによる意図的な解除ではなく、２人のプレイヤに設定された仲間期間の終了により仲間関係が自動解除される場合、仲間関係の解除が多くなる分、仲間関係を復活させたいと考える機会もまた多くなるため、仲間復活申請を簡単な操作で容易に行うことができる上記（１）の構成が好適である。
（７）本発明の他の一局面によるゲーム管理方法は、各プレイヤの端末装置と通信し、プレイヤ同士が仲間関係を構築することができるゲームの仲間管理を行うゲーム管理装置におけるゲーム管理方法であって、前記ゲーム管理装置が、仲間関係成立中の２人のプレイヤを関係付けた仲間情報を記憶するとともに、当該２人の仲間関係が解除された後も、当該２人のプレイヤを関係付けた過去の仲間情報を保持する仲間情報記憶ステップと、前記ゲーム管理装置が、プレイヤが操作する端末装置からの要求に応じて、前記仲間情報記憶ステップによって記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する仲間履歴送信ステップと、前記仲間履歴送信ステップが送信した情報を受信して前記プレイヤの過去の仲間プレイヤを表示している前記端末装置にて当該過去の仲間プレイヤを選択する操作が行われた場合に、前記ゲーム管理装置が、当該操作の情報を前記端末装置から受信して当該プレイヤから当該過去の仲間プレイヤへの仲間関係復活の申請処理を実行する仲間復活申請ステップと、を備える構成である。
（８）本発明の更に他の一局面によるプログラムは、コンピュータを上記の（１）ないし（６）の何れかの構成のゲーム管理装置として動作させるためのプログラムであって、前記コンピュータを前記ゲーム管理装置が備えている各手段として機能させるためのプログラムである。
本発明によれば、プレイヤの端末装置に過去の仲間プレイヤを表示させて所望の相手に対して簡単に仲間関係復活の申請を行えるようにするという従来にはない斬新な機能をプレイヤに提供できる。これにより、過去の仲間プレイヤと仲間関係を再構築するための機会が持てるゲーム環境をプレイヤに提供できる。
本発明の一実施の形態に係るゲームシステムの構成例を示す説明図である。 ゲーム管理装置のハード構成の一例を示すブロック図である。 端末装置のハード構成の一例を示すブロック図である。 ゲーム管理装置の機能的構成の一例を示す機能ブロック図である。 ゲーム情報管理手段の機能的構成の一例を示す機能ブロック図である。 交流手段の機能的構成の一例を示す機能ブロック図である。 ゲーム情報管理手段がデータベースサーバに保存して管理するゲーム情報の一例を示す説明図である。 仲間情報記憶手段が記憶する仲間情報の一例を示す説明図である。 仲間情報記憶部が記憶する各プレイヤの仲間に関する情報の一例を示す説明図である。 仲間情報記憶部が記憶する各プレイヤの仲間に関する情報の他の例を示す説明図である。 仲間情報記憶手段が記憶する現在および過去の仲間情報の一例を示す説明図である。 仲間情報記憶手段が記憶する過去の仲間情報の一例を示す説明図である。 メッセージ記憶部が記憶する受信メッセージ情報の一例を示す説明図である。 メイン画面の一例を示す説明図である。 仲間リスト画面の一例を示す説明図である。 メッセージ入力画面の一例を示す説明図である。 対戦モードにおけるゲーム画面の一例を示す説明図である。 助っ人選択画面の一例を示す説明図である。 対戦モードにおけるゲーム画面の他の例を示す説明図である。 過去の仲間リスト画面の一例を示す説明図である。 ゲームシステムの動作の一例を示すフローチャートである。 仲間復活申請を管理するための記憶情報の一例を示す説明図である。 ゲームシステムの動作の一例を示すフローチャートである。 ゲーム進行処理の一例を示すフローチャートである。 仲間解除時のゲームサーバの処理の一例を示すフローチャートである。 ゲームシステムにおける仲間関係復活処理の一例を示すフローチャートである。 仲間履歴送信処理の一例を示すフローチャートである。 ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。 仲間成立ポイント付与処理の一例を示すフローチャートである。 再復活制限処理の一例を示すフローチャートである。 再復活制限処理の他の例を示すフローチャートである。 仲間履歴送信処理の他の例を示すフローチャートである。 再復活制限処理の他の例を示すフローチャートである。 再復活制限処理の他の例を示すフローチャートである。 ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。 プレイヤ間のレベル差と仲間期間との関係を表すテーブルの一例を示す説明図である。 仲間期間記憶手段が記憶する仲間期間の一例を示す説明図である。 仲間リスト画面の他の例を示す説明図である。 仲間関係が成立した２人のプレイヤを対象としたゲームサーバの処理の一例を示すフローチャートである。 仲間期間決定処理の一例を示すフローチャートである。 仲間期間決定処理の他の例を示すフローチャートである。 ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。 レベル差記憶手段が記憶するレベル差の一例を示す説明図である。 レベル差記憶手段が記憶するレベル差の他の例を示す説明図である。 仲間期間の再設定処理の一例を示すフローチャートである。 仲間期間記憶手段が記憶する仲間期間の情報の他の例を示す説明図である。 交流履歴記憶手段が記憶する交流履歴の情報の一例を示す説明図である。 仲間期間の延長処理の一例を示すフローチャートである。 仲間期間の延長処理の他の例を示すフローチャートである。 親密度記憶手段が記憶する親密度の情報の一例を示す説明図である。 延長時の仲間期間の補正処理の一例を示すフローチャートである。
以下、本発明の一実施の形態に係るゲーム管理装置、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。
〔ゲームシステムの概要〕
本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図１に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク４上に設置されたゲームサーバ１と、当該ゲームサーバ１と通信可能に接続されたデータベースサーバ２と、ネットワーク４を介してゲームサーバ１と通信可能に接続できる各プレイヤの端末装置３とによって構成される。
本実施の形態のネットワーク４は、インターネットに限定されるものではなく、ゲームサーバ１と各プレイヤの端末装置３との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線（電話回線、移動体通信回線等）、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ等であってもよく、或いはインターネットとこれらを組み合わせたものであってもよい。
このゲームシステムの例において、本発明の一実施の形態に係るゲーム管理装置は、ゲームサーバ１およびデータベースサーバ２から構成される。ゲームサーバ１は、ゲームサービスを受ける各プレイヤの端末装置３からのネットワーク４を介したアクセスを受け付けて、各プレイヤのゲーム情報をデータベースサーバ２（記憶装置）に蓄積して管理し、各プレイヤにネットワーク４を介したゲームサービスを提供する。
本実施の形態では、ゲームサーバ１によるゲームサービスの提供の一形態として、各プレイヤの端末装置３に搭載されたウェブブラウザによってゲームがプレイできる、いわゆるブラウザゲームを提供する例について説明する。このブラウザゲームを提供するサービス形態では、プレイヤの端末装置３にゲーム専用のソフトウェアをダウンロード又はインストールする必要がなく、端末装置３をネットワーク４に接続できる環境であれば、プレイヤはどこでも気軽にゲームサーバ１から提供されるゲームサービスを楽しむことができる。
このゲームシステムでは、ブラウザゲーム用のプログラム（アプリケーションソフトウェア）がゲームサーバ１に実装されており、ゲームサーバ１が、各プレイヤの端末装置３における入力操作に応じてゲーム進行のための演算処理やデータ処理を実行する。そして、ゲームサーバ１は、演算処理等の実行結果に基づいてデータベースサーバ２内の各プレイヤのゲーム情報を更新するとともに、当該実行結果をプレイヤの端末装置３の画面に表示させるためのウェブページ情報（ゲーム画面データ）を各プレイヤの端末装置３に送信する。
各プレイヤの端末装置３には、プレイヤーエージェントとしてウェブサイト閲覧機能を有するウェブブラウザが搭載されており、ゲームサーバ１から送信されたウェブページ情報を端末装置３の画面に表示することができるようになっている。この端末装置３としては、例えば、携帯電話端末、ＰＨＳ（Personal Handy-phone System）端末、携帯情報端末（ＰＤＡ：Personal Digital Assistant）、携帯電話と携帯情報端末とを融合させた携帯端末であるスマートフォン、パーソナルコンピュータまたはタブレット型コンピュータなど、ネットワーク４経由でゲームサーバ１に接続してゲームサービスの提供を受けることができる様々な端末が適用できる。
また、本実施の形態で提供されるゲームは、プレイヤが、ゲームサービスを受けている他のプレイヤとコミュニケーションをとりながらプレイすることができる、いわゆるソーシャルゲームの要素を有する。例えば、本実施の形態のゲームサーバ１およびデータベースサーバ２をソーシャルネットワーキングサービス（ＳＮＳ）のシステムに組み込むことによって、ＳＮＳのサービスの一つとしてソーシャルゲームサービスを提供するゲームシステムとすることができる。このようにＳＮＳのプラットフォーム上で動作するゲームシステムによりゲームサービスをプレイヤに提供することもできるが、ゲームサーバ１およびデータベースサーバ２をＳＮＳのシステムに組み込まずに、独立したゲームシステムとして構築してもよい。
このゲームシステムにおいて、各プレイヤは、ゲームサービスを受けている１人又は複数の他のプレイヤと「仲間」という特別な関係を構築できる。あるプレイヤが他のプレイヤと仲間関係を構築するための一形態としては、２人のプレイヤの何れか一方が、他方のプレイヤに対してゲームサーバ１を介して仲間申請を行い、当該仲間申請を受けたプレイヤがゲームサーバ１を介して仲間になることを承認するという、両プレイヤ間においてなされる仲間申請とその承認の操作が挙げられる。２人のプレイヤ間で仲間関係が成立した場合、ゲームサーバ１は当該２人のプレイヤの識別情報（プレイヤＩＤ）を関係付けた仲間情報をデータベースサーバ２に登録する。そして、ゲームサーバ１は、各プレイヤを中心とする仲間グループに所属する仲間関係にある仲間プレイヤの情報をデータベースサーバ２に記憶して、プレイヤ毎の仲間管理を行う。この仲間申請、その承認およびゲームサーバ１による仲間管理の詳細については後述する。
また、各プレイヤは、必要に応じて仲間プレイヤとの仲間関係を解除することができる。そして、本実施の形態のゲームサーバ１は、２人の仲間関係が解除された後も、当該２人のプレイヤを関係付けた過去の仲間情報を、データベースサーバ２に保持するようになっている。また、ゲームサーバ１は、プレイヤが操作する端末装置３からの要求に応じて、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を、当該端末装置３へ送信するようになっている。よって、プレイヤは、自己の端末装置３を操作して、いつでも自分の過去の仲間履歴を、端末装置３の表示画面上で容易に確認することができる。
さらに、プレイヤは、端末装置３に表示されている過去の仲間プレイヤを確認して、仲間関係を復活させたい所望の相手を選択する操作を行うことで、その相手に対する仲間関係復活の申請を容易に行うことができるようになっている。これにより、プレイヤは、過去の仲間プレイヤと仲間関係を再構築する機会が与えられることになる。プレイヤから仲間関係復活の申請を受けた相手がそれを承認すれば、両者の仲間関係が復活する。
以下に、上記のようにプレイヤに過去の仲間プレイヤとの仲間関係を再構築するための機会を与えることができる、本実施の形態に係るゲーム管理装置（ゲームサーバ１等）の構成の詳細を説明する。
〔ゲーム管理装置の構成〕
上述のように本実施の形態では、ゲーム管理装置は、ゲームサーバ１およびデータベースサーバ２から構成される。図２にゲームサーバ１のハード構成の一例を示している。同図に示すように、ゲームサーバ１は、主に、ＣＰＵ（Central Processing Unit）１１と、主記憶装置としてのＲＯＭ（Read Only Memory）１２及びＲＡＭ（Random Access Memory）１３と、補助記憶装置１４と、通信制御部１５と、入出力制御部１６とを備えており、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン１７を介して相互に接続されている。なお、バスライン１７と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。
ＣＰＵ１１は、システムソフトウェアやゲームプログラム等のアプリケーションソフトウェアの命令を解釈して実行し、ゲームサーバ１全体の制御を行う。ＲＯＭ１２は、ゲーム管理装置１の基本的な動作制御に必要なプログラム等を記憶している。ＲＡＭ１３は、各種プログラム及びデータを記憶し、ＣＰＵ１１に対する作業領域を確保する。
補助記憶装置１４は、ゲームプログラム等のアプリケーションソフトウェアや各種データ等を格納する記憶装置である。補助記憶装置１４としては、例えばハードディスクドライブなどを用いることができる。ゲームサーバ１（コンピュータ）をゲーム管理装置として動作させるための本実施の形態のプログラムも、この補助記憶装置１４に記憶されており、当該プログラムはゲームサーバ１の起動時に補助記憶装置１４からバスライン１７を介してＲＡＭ１３へとロードされ、当該ＣＰＵ１１によって実行される。
通信制御部１５は、ネットワーク４と接続される通信インタフェース１５ａを備え、ネットワーク４を介した各プレイヤの端末装置３との間の通信を制御する。また、通信制御部１５は、ネットワーク４に接続されている図示しないサーバとの通信も制御するようになっている。例えば、ゲームサーバ１をＳＮＳに組み込んだシステム構成とした場合、ゲームサーバ１の通信制御部１５は、ＳＮＳサーバとの間の通信を制御する。
入出力制御部１６は、データベースサーバ２と通信可能に接続されており、ＣＰＵ１１がデータベースサーバ２に対してデータ（レコード）の読み書きを実行するときの入出力制御を行うデータベースインタフェースである。
データベースサーバ２は、ゲームサーバ１が管理する各プレイヤのゲーム情報を記憶する領域を有する記憶装置として、例えばＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成の大容量ハードディスク装置を具備する。このデータベースサーバ２は、例えば、各プレイヤを一意に識別する識別情報（プレイヤＩＤ）と対応付けて、各プレイヤの各種ゲーム情報（プレイヤ名、レベル、ゲーム内ポイント、所持アイテムなど）を記憶するリレーショナルデータベース、オブジェクトデータベース又はオブジェクト関係データベース等として構築することができる。
本実施の形態では、ゲーム管理装置がゲームサーバ１およびデータベースサーバ２から構成される例を示すが、これに限定されるものではない。例えば、ゲームサーバ１にデータベースサーバ２の機能を持たせて、ゲーム管理装置をゲームサーバ１のみで構成することもできる。また、ゲームサーバ１の有する各機能を複数のサーバに分散して持たせて、ゲームサーバ１を複数台のサーバとして構成することもできる。例えば、プレイヤが端末装置３を操作してゲームサーバ１へアクセスした場合に、当該プレイヤが正規のプレイヤかどうかを判別する認証機能を有する認証サーバを、ゲームサーバ１のメインサーバとは別に設け、メインサーバと認証サーバとでゲームサーバ１を構成してもよい。他の構成例としては、プレイヤが課金対象のアイテムをゲーム内で購入した場合に課金管理を行う課金管理サーバを、ゲームサーバ１のメインサーバ等とは別に設け、メインサーバ、認証サーバおよび課金管理サーバによりゲームサーバ１を構成してもよい。
また、本ゲームサービスを利用するプレイヤ数が数十万人、数百万人、あるいはそれ以上となると、多数のプレイヤの端末装置３からの巨大なアクセスにも耐え得るサーバシステムの構築が求められるため、ネットワーク４上に複数のゲームサーバ１を設けて冗長化（多重化）を図ることにより、負荷分散型のシステム構成としてもよい。この場合、複数のゲームサーバ１間の負荷を調整するためのロードバランサを設けることが望ましい。
次に、本実施の形態に係るゲームサーバ１にアクセスしてゲームサービスの提供を受けるプレイヤの端末装置３の構成を説明する。
〔端末装置の構成〕
プレイヤが操作する端末装置３としては、上述のように携帯電話端末やスマートフォンをはじめとして、ウェブサイト閲覧機能を有する様々な端末を適用できるが、本実施の形態では、携帯電話端末を例示してその構成を説明する。なお、携帯電話端末以外の端末装置３についても、ウェブサイト閲覧機能を用いてゲーム画面を表示したり、ゲームを実行するための入力操作を行うといった、ゲームをプレイする上で必要となる基本的な構成は、携帯電話端末と同様である。
ウェブサイト閲覧機能等を有する携帯電話端末は、フィーチャーフォン（Feature phone）やスマートフォン（smartphone）とも呼称され、図３にその構成例を示している。同図に示すように、端末装置３は、主に、ＣＰＵ３１と、主記憶装置としてのＲＯＭ３２及びＲＡＭ３３と、画像処理部３４と、表示部３５と、サウンド処理部３６と、音声入力部３７と、音声出力部３８と、補助記憶装置３９と、操作入力部４０と、通信制御部４１とを備えており、構成要素３１〜３４、３６および３９〜４１はバスライン４２を介して相互に接続されている。なお、バスライン４２と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。
ＣＰＵ３１は、ウェブブラウザを含む各種プログラムの命令を解釈して実行し、端末装置３全体の制御を行う。ＲＯＭ３２には、端末装置３の基本的な動作制御に必要なプログラム等が記憶されている。また、ＲＡＭ３３には、ＲＯＭ３２または補助記憶装置３９からロードされた各種プログラムやデータが記憶され、ＣＰＵ３１に対する作業領域を確保する。ＨＴＭＬ等で記述されたゲーム画面データを表示するウェブブラウザは、ＲＯＭ３２または補助記憶装置３９に記憶されており、ＲＡＭ３３にロードされてＣＰＵ３１によって実行される。また、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインソフトウェアを、ウェブブラウザと共にＲＯＭ３２または補助記憶装置３９に記憶していてもよい。
画像処理部３４は、ＣＰＵ３１からの画像表示命令に基づいて表示部３５を駆動し、当該表示部３５の画面に画像を表示させる。表示部３５には、液晶ディスプレイヤ有機ＬＥ（Electro-Luminescence）ディスプレイ等の既知の種々の表示装置が適用できる。
サウンド処理部３６は、音声入力部３７から音声が入力されたときにアナログ音声信号をデジタル音声信号に変換するとともに、ＣＰＵ３１からの発音指示に基づいてアナログ音声信号を生成して音声出力部３８に出力する。音声入力部３７は、端末装置３に内蔵されたマイクロフォンからなり、電話通信する場合や録音を行う場合などに用いられる。音声出力部３８は、電話通信時の受話スピーカおよび電話着信音やゲーム実行時の効果音などを出力するスピーカからなる。
補助記憶装置３９は、各種プログラムやデータ等を格納する記憶装置である。補助記憶装置３９としては、携帯電話端末の内部メモリとして、例えばフラッシュメモリドライブ等を用いることができ、また、携帯電話端末の外部メモリとして、例えばメモリカードリーダライタ等を用いることができる。
操作入力部４０は、プレイヤの操作入力を受け入れて当該操作入力に対応した入力信号を、バスライン４２を介してＣＰＵ３１に出力するものである。操作入力部４０の例としては、端末装置３の本体に設けられた方向指示ボタン、決定ボタン、英数文字等入力ボタンなどの物理的ボタンがある。また、表示部３５の画面にタッチパネル（接触入力式のインタフェース）を搭載することによって表示部３５をいわゆるタッチスクリーンとして構成している端末装置３の場合、当該タッチパネルも操作入力部４０となる。
通信制御部４１は、通信インタフェース４１ａを備え、ゲーム操作時等にデータ通信するための通信制御機能および携帯電話端末として音声データを送受信するための通信制御機能等を有している。ここで、データ通信用の通信制御機能には、例えば、無線ＬＡＮ接続機能、無線ＬＡＮや携帯電話回線網を介したインターネット接続機能、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信機能などが含まれる。通信制御部４１は、ＣＰＵ３１からの命令に基づいてゲーム装置１を無線ＬＡＮやインターネット等に接続するための接続信号を発信するとともに、通信相手側から送信されてきた情報を受信してＣＰＵ３１へ供給する。
なお、端末装置３には、その他にもＧＰＳ（Global Positioning System）信号受信回路、ＣＣＤ（Charge Coupled Device）イメージセンサ等の撮像装置（カメラ）、３軸加速度センサなどが備えられていてもよく、例えば、ＧＰＳ位置情報などをゲーム内で活用してもよい。
上記構成の端末装置３において、ゲームサービスを受けようとするプレイヤは、ウェブブラウザを立ち上げてゲームサーバ１が管理するゲームサイトにアクセスする操作を行う。このアクセスがゲームサーバ１に認証された場合、端末装置３の通信制御部４１がゲームサーバ１から送信されてくるＨＴＭＬ等で記述されたゲーム画面データを受信し、ＣＰＵ３１がウェブブラウザを実行してゲーム画面を表示部３５に表示させる。ここでプレイヤは、ゲーム画面に表示されている選択可能なボタンオブジェクトやハイパーリンクを、操作入力部４０を操作して選択入力する。この選択入力に応じてゲームサーバ１がゲームを進行させ、新たなゲーム画面データを端末装置３に送信する。そして、この新たなゲーム画面が端末装置３の表示部３５に表示され、以下、同様に、プレイヤは、表示部３５に表示されているゲーム画面で選択可能なボタンオブジェクト等を選択する操作により、ゲームサーバ１が提供するゲームをプレイすることができるようになっている。
〔ゲーム管理装置の機能的構成〕
次に、上記のように構成されたゲーム管理装置（ゲームサーバ１およびデータベースサーバ２）の主要な機能について説明する。図４は、ゲーム管理装置の主要機能ブロック図である。
ゲーム管理装置は、主に、ゲーム情報管理手段５１、ゲーム進行手段５２、認証手段５３、仲間管理手段５４、交流手段５５、仲間履歴送信手段１０１および仲間復活申請手段１０２を備えている。これらの各手段は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。
ゲーム情報管理手段５１は、各プレイヤのゲーム情報をデータベースサーバ２に蓄積して管理する。ゲーム情報管理手段５１で管理されるゲーム情報の項目は、本ゲームサーバ１がプレイヤに提供するゲームサービスの内容によって異なる。
本ゲームサーバ１によって提供されるゲームの例としては、野球、サッカー、ゴルフなどの各種スポーツを題材としたスポーツゲーム、戦闘を題材とした戦闘ゲーム、音楽シミュレーションゲーム、その他種々のロールプレイングゲーム・育成ゲーム・シミュレーションゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、ゲームサーバ１がゲームサービスとして野球ゲームを提供する場合について、以下に説明する。
本実施の形態では、プレイヤがゲーム内において選手キャラクタを所有し、当該選手キャラクタを用いてゲーム内で他のプレイヤと試合（対戦）を行うことができる野球ゲームを例に挙げる。プレイヤが所有する選手キャラクタは、当該選手キャラクタの形態を端末装置３の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手カードとしてゲームサーバ１で管理されるとともに、プレイヤの端末装置３の画面に表示される。図１３には、プレイヤの端末装置３の画面に表示される選手カード７１を例示しており、選手キャラクタの形態およびカードのレア度（希少価値の高さを☆の多さで示したもの）などを表記したデジタル選手カードとして画面上に表示される。プレイヤは、ゲームを進行させながら選手カードを集め、自分だけのオリジナルチームを結成し、他のプレイヤと対戦してランキングを競うことができる。また、プレイヤは、集めた選手カード同士を合成することによって選手カード（選手キャラクタ）の能力を向上させる（すなわち、選手を育成する）ことができ、より強いチーム作りを目指してゲームを楽しむことができるようになっている。
このような野球ゲームにおいて、各プレイヤのゲーム情報を管理するゲーム情報管理手段５１は、図５に示すように、プレイヤ情報記憶手段５１ａ、レベル情報記憶手段５１ｂ（ゲームレベル記憶手段）、所有選手カード記憶手段５１ｃ、所有ポイント記憶手段５１ｄ、所有コイン記憶手段５１ｅ、所有アイテム記憶手段５１ｆ、試合結果記憶手段５１ｇおよびランキング記憶手段５１ｈなどを備えている。図７には、ゲーム情報管理手段５１の各記憶手段５１ａ〜５１ｈがデータベースサーバ２に記憶して管理する、各プレイヤのゲーム情報の一例（この例ではプレイヤＩＤ＝“０００００１”の１人分のゲーム情報）を示している。
プレイヤ情報記憶手段５１ａは、各プレイヤを一意に識別するプレイヤＩＤと対応付けて、ログインＩＤ、パスワード、プレイヤ名（ゲーム内で使用するニックネーム等）、チーム名等の各プレイヤに関するプレイヤ情報を、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。ここで、ログインＩＤおよびパスワードは、各プレイヤが端末装置３を操作してゲームサーバ１にアクセスしたときのログイン認証に用いられる。プレイヤ名およびチーム名は、プレイヤがゲームサービスを受けるための会員登録をした際や、ゲームを初めて実行した際に、プレイヤが自ら設定した任意の情報である。プレイヤ名およびチーム名は、必要に応じてゲーム画面に表示される。
レベル情報記憶手段５１ｂは、プレイヤＩＤと対応付けて、ゲームレベルとしてのプレイヤのレベルや所属リーグのレベル等のレベル情報を、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。本野球ゲームでは、例えば、プレイヤがゲームを進行させることにより経験値が蓄積され、当該経験値が一定量に達することによりプレイヤのレベルがアップするようになっている。また、本野球ゲームでは、例えば、複数の異なるレベルのリーグが存在し、各プレイヤのチームが何れかのリーグに所属して、同リーグの他のプレイヤのチームと自動で試合（リーグ戦）を行うようになっている。また、このリーグ戦の成績に応じて、異なるリーグに所属するプレイヤのチーム同士の入替戦が自動で実行され、プレイヤのチームが所属するリーグレベルが変化するようになっている。レベル情報記憶手段５１ｂは、このプレイヤのレベルや所属リーグのレベルを、プレイヤＩＤと対応付けて記憶する。
所有選手カード記憶手段５１ｃは、プレイヤＩＤと対応付けて、ゲーム内でプレイヤが獲得して所有している選手カードの情報を、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。この選手カードの情報の例としては、選手カードを一意に識別するための識別情報（選手カードＩＤ）、選手の能力の高さを示す能力値およびレギュラー選手フラグなどがある。
図７では、３つの能力項目（能力１〜３）に対して選手の能力値を設定できる例を示している。能力項目の例としては、選手カードが野手の場合は、能力１〜３を「打撃」、「走力」、「守備」等とすることができ、また選手カードが投手の場合は、能力１〜３を「球威」、「制球」、「変化」等とすることができる。能力項目はこの例に限らず、増減可能である。レギュラー選手フラグとは、プレイヤが所有している選手カードのうち、他のプレイヤのチームとの試合に出場するレギュラー選手（チームオーダーに組み込まれた選手）であるか、それともレギュラー選手以外の控え選手であるかを判別するフラグであり、これが「１」のときレギュラー選手の選手カードとして登録されていることを示す。プレイヤは、端末装置３を操作することにより、所有している選手カードからレギュラー選手を選択したり、チームオーダーを設定したりすることができるようになっている。
また、データベースサーバ２には、選手カードＩＤと対応付けられて、選手カードの画像データ、選手名、ポジション、所属球団、能力値（合成により強化されていない初期値）などが記憶された選手カードデータベースが存在し、ゲーム情報管理手段５１は、所有選手カード記憶手段５１ｃが記憶している選手カードＩＤに基づいて、当該選手カードＩＤに対応する選手カードの画像データ等を取得できるようになっている。
所有ポイント記憶手段５１ｄは、プレイヤＩＤと対応付けて、ゲーム内でプレイヤが所有している各種ポイント（ポイントに準ずる値などを含む）を、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。本ゲームにおいては、様々なゲームモードが存在し、ゲームモードに応じて様々なポイントを獲得したり、獲得したポイントを使用したりできるようになっている。
図７に示すように、ポイントの例としては、上述の経験値の他、行動力ポイント、運営コスト、強化ポイント、交流ポイントなどがある。行動力ポイントは、当該行動力ポイントを消費しながら選手カードを探索して選手をスカウトするという「スカウトモード」で使用される。運営コストは、他のプレイヤを指定して個別対戦の試合を行う「試合モード」で使用されるものであり、試合を運営する場合に必要なコスト（ポイント）という位置付けで、当該個別対戦を行うことにより消費される。例えば、ゲーム中に消費されて減った行動力ポイントや運営コストは、時間の経過により回復する（例えば、３分経過する毎に１ポイントずつ回復する）ようにしたり、前記経験値が一定量に達してプレイヤのレベルがアップすることにより回復するようにしたりできる。
また、前記の強化ポイントは、プレイヤが所有する選手カード同士を合成することによって選手カードの能力を向上させる「強化モード」で使用されるものであり、当該合成を行うことにより消費される。この強化ポイントは、例えばスカウトモードの実行や試合モードの実行等によって獲得できるようにすることができる。
また、前記交流ポイントは、プレイヤが他のプレイヤ（特に仲間プレイヤ）と挨拶等の交流を行うことによって獲得できるポイントである。交流の具体例等の詳細については後述する。この交流ポイントは、例えば、ゲームサーバ１が管理している全ての選手カードの中から乱数等に基づく抽選で所定枚数（例えば１枚）の選手カードを獲得できる「抽選モード」で使用可能であり、所定の交流ポイントにつき１回の選手カード抽選を受けることができる。
所有コイン記憶手段５１ｅは、プレイヤＩＤと対応付けて、ゲーム内でプレイヤが所有しているコイン（前記ポイントとは別のゲーム内通貨）を、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。このコインは、例えば、課金対象のアイテムを獲得する等の際に必要となるものである。
所有アイテム記憶手段５１ｆは、プレイヤＩＤと対応付けて、ゲーム内でプレイヤが獲得したアイテムを、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。図７に示すように、アイテムの例としては、回復アイテム、パズルカードのピース、フェイクカードなどがある。回復アイテムは、ゲーム中に消費して減った前述の行動力ポイントおよび／または運営コストを、時間の経過を待たずに一瞬で最大値まで回復させるアイテムである。例えば、回復アイテムは、前記コインを消費して購入したり、ゲーム内で所定のボーナス条件を満たしたりすることにより獲得できる。
パズルカードのピースは、所定数のピース（例えばＰ１〜Ｐ６の６つのピース）を全部集めてパズルカードを完成させることで強力な（能力値の高い）選手カードを入手することができるアイテムである。例えば、パズルカードのピースは、前記スカウトモードの実行時に乱数等に基づく抽選で当選した場合に獲得でき、また前記試合モードで他のプレイヤが所有しているピースを狙って対戦して勝利した場合に、当該対戦相手のプレイヤから奪取できるようになっている。
フェイクカードは、前記パズルカードのピースにセットしておくことにより、前記試合モードの対戦で他のプレイヤに負けても、狙われたピースを一度だけ奪取されないようにできるアイテムである。例えば、フェイクカードは、前記コインを消費して購入したり、ゲーム内で所定のボーナス条件を満たしたりすることにより獲得できる。
試合結果記憶手段５１ｇは、プレイヤＩＤと対応付けて、プレイヤのチームが他のプレイヤのチームと対戦した試合を一意に特定するための試合ＩＤを、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。ここで、試合ＩＤにより一意に特定される試合は、プレイヤが対戦相手を指定して行う個別対戦の試合、およびゲームサーバ１により自動で行われるリーグ戦の試合を含む。
また、データベースサーバ２は、試合ＩＤと対応付けられて、試合日時（現実世界の試合開始または終了の時間）、勝利したチームのプレイヤＩＤ、敗北したチームのプレイヤＩＤ、対戦スコア、勝利投手キャラクタ、敗戦投手キャラクタ、本塁打を打った選手キャラクタ、試合寸評情報などの試合結果に関する情報が記憶された試合データベースを備えている。そして、ゲーム情報管理手段５１は、試合結果記憶手段５１ｇが記憶している試合ＩＤに基づいて、当該試合ＩＤに対応する試合結果に関する情報を、試合データベースから取得できるようになっている。
ランキング記憶手段５１ｈは、プレイヤＩＤと対応付けて、前記リーグ戦や入れ替え戦におけるプレイヤのチームの勝利数および敗戦数、ならびに勝利数・敗戦数に基づく所属リーグ内の順位などのランキング情報を、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。例えば、リーグ戦が現実世界における月曜日〜金曜日の各日の所定時間に所定の試合数（例えば各日１２試合）自動的に行われ、また、入れ替え戦が現実世界における土曜日および日曜日の所定時間に所定の試合数（例えば各日１２試合）自動的に行われるものとする。この場合、図７に示すように、ランキング記憶手段５１ｈは、現実世界の月曜日〜日曜日の各日についてのランキング情報を記憶し、毎週、ランキング情報を最新の情報に更新する。
次に、図４に示すゲーム進行手段５２について説明する。ゲーム進行手段５２は、プレイヤによる端末装置３に対する操作に応じてゲームを実行し、当該実行結果に応じたゲーム画面データを生成してこれを端末装置３に送信し、端末装置３にプレイヤの操作に応じたゲーム画面を表示させることによってゲームを進行させる機能を有する。図４に示すように、このゲーム進行手段５２は、ゲーム実行手段５２ａと、ゲーム画面生成手段５２ｂと、ゲーム画面送信手段５２ｃとを備えている。
プレイヤの端末装置３のウェブブラウザによってゲーム画面が表示されているとき、プレイヤがゲーム画面上の選択可能なボタンオブジェクトやハイパーリンクが設定された文字列等を選択する操作を行った場合、当該操作に応じたゲーム画面のリクエストが端末装置３のウェブブラウザによってゲームサーバ１へ送信される。このリクエストを受信したゲームサーバ１では、ゲーム実行手段５２ａが、当該リクエストに応じてプレイヤのゲーム情報を読み出して演算やデータ処理を行うことによってゲームを実行する。
例えば、対戦モードで他のプレイヤのチームと対戦するという操作がプレイヤによって行われた場合を例に挙げると、ゲーム実行手段５２ａは、対戦を行う両プレイヤのプレイヤＩＤに対応した両チームの選手カード情報（試合に出場するレギュラー選手の選手カード情報）をデータベースサーバ２から読み出す。そして、ゲーム実行手段５２ａは、両チームの選手カードの能力値等に基づいて、勝敗を決定する演算を行う。この勝敗決定の演算の例としては、単純に両チームの選手カードの能力値の合計が高い方を勝利チームとしてもよいし、能力値の合計が高い方のチームが勝利する確率を高くして勝利チームを確率演算により求めてもよい。また、ゲーム実行手段５２ａは、勝敗を決定する演算の前に、チームを構成する選手カードの組み合わせに基づいて、勝敗に影響を与える様々な効果演出を発生させるか否かを決定する演算を行ってもよい。
ゲーム画面生成手段５２ｂは、ゲーム実行手段５２ａによる実行結果に応じて、例えばＨＴＭＬデータからなるゲーム画面データを生成する。ＨＴＭＬデータには、データベースサーバ２から読み出された選手カード等の画像データを含めてもよい。また、ＨＴＭＬデータには、端末装置３のウェブブラウザのプラグインによって動作するスクリプト（プログラム）が埋め込まれていてもよい。ゲームサーバ１から提供されたスクリプトが端末装置３で実行される場合は、端末装置３で表示されるゲーム画面を動画とすることも可能である。
ゲーム画面送信手段５２ｃは、ゲーム画面生成手段５２ｂにより生成されたゲーム画面データ（ＨＴＭＬデータ等）を、ゲーム画面のリクエストに対するレスポンスとしてプレイヤの端末装置３へ送信する。このゲーム画面データを受信したプレイヤの端末装置３では、ウェブブラウザによって表示部３５にゲーム画面が表示される。
次に、認証手段５３について説明する。認証手段５３は、ゲームサービスを受けようとするプレイヤが端末装置３を操作してゲームサーバ１にアクセス（ログイン）しようとした際、当該プレイヤのゲーム参加資格の有無を判断してログイン認証を行う。この認証の例としては、プレイヤＩＤと対応付けられたログインＩＤおよびパスワードに基づく認証がある。例えば、プレイヤが初めてゲームサービスを利用するときに、会員情報としてログインＩＤ（任意の英数文字やメールアドレス等）およびパスワードをゲームサーバ１に登録する。そして、次回からのゲームサーバ１へのログイン時には、プレイヤが端末装置３を操作してログインＩＤおよびパスワードをゲームサーバ１へ送信する。このとき、ゲームサーバ１の認証手段５３が、プレイヤの端末装置３から受信したログインＩＤおよびパスワードの組み合わせが登録済みであるか否かを判断し、ログイン認証を行う。
また、ＳＮＳのシステムに本ゲームシステムを組み込む場合、ＳＮＳの会員登録情報（ログインＩＤおよびパスワード）をそのまま本ゲームシステムのゲームサービスを受けるための利用登録情報としてもよい。例えば、プレイヤの端末装置３がＳＮＳサーバにログインしている状態で、ゲームサーバ１が管理するゲームサイトに最初にアクセスした際、ＳＮＳサーバからゲームサーバ１へ自動的にプレイヤのログインＩＤおよびパスワードが転送され、これによってプレイヤが改めてログインＩＤおよびパスワードを登録することなくゲームサービスの利用登録ができるようにしてもよい。
また、プレイヤがゲームサーバ１にアクセスする度にログインＩＤおよびパスワードを入力する手間を省略できるように、端末装置３である携帯電話やスマートフォンの個体識別番号（電話番号とは別の端末を一意に識別するための情報）、または契約者固有ＩＤ（端末の契約者を一意に識別するための情報であって、機種変更を行っても契約者が同一である限りは変更されないＩＤ）を利用した認証を行ってもよい。すなわち、プレイヤが端末装置３を操作して会員登録した際に、当該端末装置３から送信されてくるデータに含まれる個体識別番号または契約者固有ＩＤをゲームサーバ１が取得し、ログインＩＤおよびパスワードとともに、当該個体識別番号または契約者固有ＩＤもプレイヤＩＤと対応付けてデータベースサーバ２に記憶しておくのである。そして、認証手段５３は、端末装置３からアクセス要求を受けた際には、個体識別番号または契約者固有ＩＤが登録済みであるか否かを判断してログイン認証を行う。これにより、ゲームサーバ１へのアクセス時には、プレイヤはログインＩＤおよびパスワードの入力を省略してログインすることが可能となる。
また、プレイヤがゲームサーバ１にアクセスする度にログインＩＤおよびパスワードを入力する手間を省略できる別の方法としては、HTTP cookieの情報（以下、Cookieと称する）を利用する方法もある。すなわち、プレイヤが端末装置３を操作して会員登録した際に、ゲームサーバ１がログインＩＤおよびパスワードに対応した個体識別情報を発行してデータベースサーバ２へ登録するとともに、当該個体識別情報をCookieとして端末装置３へ送信する。このとき、端末装置３のブラウザは、受信したCookieを端末装置３内へ記憶する。次回からのゲームサーバ１へのアクセスの際には、端末装置３のブラウザがページ閲覧要求とともにCookieをゲームサーバ１へ送信するので、認証手段５３は、端末装置３からアクセス要求を受けた際には、Cookieの個体識別番号が登録済みであるか否かを判断してログイン認証を行うことができる。
次に、仲間管理手段５４について説明する。仲間管理手段５４は、仲間関係が成立している２人のプレイヤを関係付けた仲間情報をデータベースサーバ２（記憶装置）に記憶する仲間情報記憶手段５４ａを備えている。図８には、仲間情報記憶手段５４ａがデータベースサーバ２に記憶する仲間情報の一例を示している。
図８に示すように、仲間情報記憶手段５４ａは、ある２人のプレイヤ間で仲間関係が成立したときに、仲間申請をしたプレイヤのプレイヤＩＤと当該仲間申請を承認したプレイヤのプレイヤＩＤとを関係付けた仲間情報をデータベースサーバ２へ記憶する。そして、仲間管理手段５４は、各仲間情報にこれらを一意に識別するための仲間情報ＩＤを付加し、仲間情報ＩＤに基づいて仲間管理を行う。
図８の例では、仲間申請したプレイヤＩＤ＝“０００００１”のプレイヤＡと、それを承認したプレイヤＩＤ＝“０００００２”のプレイヤＢとの２人のプレイヤを関係付けた仲間情報が、仲間情報ＩＤ＝“１”の仲間情報としてデータベースサーバ２に登録されている。これにより、プレイヤＡにとってプレイヤＢは仲間関係にある仲間プレイヤであり、プレイヤＢにとってもプレイヤＡは仲間プレイヤとなる。
また、各プレイヤは複数の仲間を作ることができ、各プレイヤを中心とする仲間グループを構成することが可能である。図８の例では、プレイヤＩＤ＝“０００００１”のプレイヤＡは、プレイヤＩＤ＝“０００００５”および“００００３５”のプレイヤとも仲間関係を構築している。そして、仲間管理手段５４は、各プレイヤを中心とする仲間グループに所属する仲間関係にある仲間プレイヤの情報をデータベースサーバ２に記憶して、プレイヤ毎の仲間管理を行う。
図９（ａ）には、仲間管理手段５４がデータベースサーバ２に記憶している仲間情報等に基づいて管理している、各プレイヤの仲間に関する情報の一例を示している。仲間管理手段５４の仲間情報記憶手段５４ａは、プレイヤＩＤと対応付けて、仲間数の上限の情報、すでに仲間の関係になっている仲間プレイヤのプレイヤＩＤ、仲間申請中のプレイヤのプレイヤＩＤ、および仲間申請を受けているが未承認のプレイヤのプレイヤＩＤなどの仲間に関する情報を、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。図９（ａ）の例では、プレイヤＩＤ＝“０００００１”のプレイヤ１人分の仲間に関する情報を示しており、仲間数の上限は４５人、当該プレイヤの仲間プレイヤは１０人、仲間申請中のプレイヤは１人、仲間申請を受けているが未承認のプレイヤは０人である。
本実施の形態の野球ゲームでは、仲間をつくることによって、後述の仲間成立ポイント付与手段１０３により、仲間関係になった両プレイヤにボーナスポイントが付与される（例えば、前記行動力ポイントや運営コストの最大値を所定ポイントだけ増加させることができる）。また、仲間プレイヤと協力して試合をしたり、仲間同士で選手カードのプレゼントや応援を行ったりすることで、ゲームを有利に進めることができるゲーム仕様となっている。このようにゲーム内で仲間をつくることによるメリットをプレイヤに付与することにより、仲間を作ることを促進している。
但し、各プレイヤが他のプレイヤと仲間関係を構築することができる仲間数には上限を設定することができる。仲間数の上限としては、各プレイヤに共通の１つの上限（例えば、５０人）を設けることができる。あるいは、各プレイヤのゲームの進行度合いに応じて、仲間数の上限が所定範囲（例えば１０人〜９９人の範囲）で変動するようにしてもよい。本実施の形態では、仲間数の上限が１０人〜９９人の範囲で変動し、プレイヤのレベルが高くなるほど、仲間数の上限が大きくなるようにしている。これにより、プレイヤは、より多くの仲間を作ってゲームを有利にするために、ゲームを継続的に進めてレベルアップを図ろうとする動機付けを与えられることになる。仲間情報記憶手段５４ａは、プレイヤＩＤと対応付けて、各プレイヤの仲間数の上限を記憶しており、仲間管理手段５４が各プレイヤの仲間数の上限を管理する。
本実施の形態において、２人のプレイヤが仲間になるには、両プレイヤの何れか一方が、他方のプレイヤに対してゲームサーバ１を介して仲間申請を行う。この仲間申請の操作例としては、先ず、仲間を作ろうとするプレイヤが、端末装置３の画面上に仲間候補の対象者をリストアップする操作を行う。このとき、プレイヤは、仲間候補のプレイヤレベルを指定することができる。このプレイヤによる操作に応じて、ゲームサーバ１が仲間候補の対象者をリストアップした画面データを送信することにより、複数の仲間候補がリストアップされた画面がプレイヤの端末装置３に表示される。ここで、プレイヤは、画面上にリストアップされた対象者のプレイヤレベルや所属リーグレベル等を確認し、仲間にしたいプレイヤを選択して仲間申請の操作を行う。
例えば、プレイヤＩＤ＝“０００００１”のプレイヤＡが、プレイヤＩＤ＝“０００００２”のプレイヤＢに対して仲間申請の操作を行った場合を考える。図９（ａ）に示すように、この操作に応じてゲームサーバ１の仲間情報記憶手段５４ａは、仲間申請を行ったプレイヤＡのゲーム情報として、当該プレイヤＡのプレイヤＩＤ＝“０００００１”と対応付けて、被申請者であるプレイヤＢのプレイヤＩＤ＝“０００００２”を、「申請中のプレイヤＩＤ」として記憶する。
さらに、図１０（ａ）に示すように、仲間情報記憶手段５４ａは、被申請者であるプレイヤＢのゲーム情報として、当該プレイヤＢのプレイヤＩＤ＝“０００００２”と対応付けて、仲間申請を行ったプレイヤＡのプレイヤＩＤ＝“０００００１”を、「未承認のプレイヤＩＤ」として記憶する。そして、ゲームサーバ１は、その後、プレイヤＢの端末装置３がゲームサーバ１にログインしたときに、プレイヤＡから仲間申請があった旨を通知する。
そして、仲間申請を受けたプレイヤＢは、ゲームサーバ１から受信したプレイヤＡのプレイヤレベルや所属リーグレベル等の情報を、端末装置３の画面上で確認し、仲間として承認するか拒否するかを選択する操作を行う。ここで、プレイヤＢが仲間として承認する操作を行った場合、この操作に応じてゲームサーバ１の仲間管理手段５４は、プレイヤＡとプレイヤＢとの仲間関係を成立させ、図８に示すように両プレイヤＡ・ＢのプレイヤＩＤを関係付けた仲間情報をデータベースサーバ２に登録する。そして、仲間情報記憶手段５４ａは、図９（ｂ）に示すように、プレイヤＡのゲーム情報として、当該プレイヤＡのプレイヤＩＤ＝“０００００１”と対応付けて、プレイヤＢのプレイヤＩＤ＝“０００００２”を、「仲間プレイヤＩＤ」として記憶し、「申請中のプレイヤＩＤ」からプレイヤＢのプレイヤＩＤを削除する。
さらに、図１０（ｂ）に示すように、仲間情報記憶手段５４ａは、プレイヤＢのプレイヤＩＤ＝“０００００２”と対応付けて、プレイヤＡのプレイヤＩＤ＝“０００００１”を、「仲間プレイヤＩＤ」として記憶し、「未承認のプレイヤＩＤ」からプレイヤＡのプレイヤＩＤを削除する。そして、ゲームサーバ１は、その後、プレイヤＡの端末装置３がゲームサーバ１にログインしたときに、プレイヤＢから仲間の承認があった旨を通知する。
また、仲間情報記憶手段５４ａは、２人の仲間関係が解除された後も、当該２人のプレイヤを関係付けた過去の仲間情報を保持（記憶）する。以下に、仲間情報記憶手段５４ａが過去の仲間情報を保持する形態について説明する。
図１１Ａは、仲間情報記憶手段５４ａがデータベースサーバ２の所定の記憶領域に記憶している、現在および過去の仲間情報の一部を抜粋して示したものである。この図１１Ａには、全プレイヤの中から、現在仲間関係にある一対のプレイヤ及び過去に仲間関係にあった一対のプレイヤが、併せてリストアップされている。図１１Ａに例示するように、仲間情報記憶手段５４ａは、仲間関係が解除された２人の仲間情報に、仲間解除フラグを立てて、過去の仲間情報として保持するようになっている。図１１Ａの例では、仲間解除フラグとして“１”が設定されている仲間情報が過去の仲間情報であり、仲間解除フラグが“０”の仲間情報が現在成立中の仲間情報である。
ここで、プレイヤＩＤ＝“０００００１”のプレイヤＡに注目して、図１１Ａの説明を続ける。プレイヤＡの仲間情報とは、仲間申請をしたプレイヤＩＤまたは承認したプレイヤＩＤの何れかに“０００００１”が含まれている仲間情報であり、仲間情報ＩＤ＝“１”、“２”、“３”、“２２”、“２３”、“８１”の仲間情報がこれに該当する。これらのうち、仲間情報ＩＤ＝“３”、“８１”の仲間情報は、仲間解除フラグが“０”であるため、現在の仲間情報である。よって、プレイヤＩＤ＝“００００３５”、“０００１１０”の各プレイヤは、プレイヤＡの現在の仲間プレイヤである。一方、仲間情報ＩＤ＝“１”、“２”、“２２”、“２３”の仲間情報は、仲間解除フラグが“１”であるため、過去の仲間情報である。よって、プレイヤＩＤ＝“０００００２”、“０００００５”、“００００１０”、“００００１２”の各プレイヤは、プレイヤＡの過去の仲間プレイヤである。
このように、仲間情報に仲間解除フラグを付加することにより、現在の仲間情報と過去の仲間情報とを区別できるようにして、過去の仲間情報を保持することができる。この形態では、僅か１ビットの仲間解除フラグを設定するだけで、現在の仲間情報の内容をそのまま援用して過去の仲間情報を保持できるので、好ましい形態である。
過去の仲間情報を保持する他の形態としては、現在の仲間情報とは別に、過去の仲間情報をデータベースサーバ２に新規登録する形態もある。例えば、図１１Ｂに示すように、仲間情報記憶手段５４ａは、２人のプレイヤ間の仲間関係が解除されたときに、当該２人のプレイヤの各々のプレイヤＩＤを関係付けた過去の仲間情報を、データベースサーバ２へ記憶する。図１１Ｂの例では、仲間関係を自主的に解除したプレイヤＩＤと、相手から仲間関係を自主的に解除されたプレイヤＩＤとを関係付けて記憶する。そして、仲間管理手段５４は、過去の仲間情報を一意に識別するための識別情報（過去の仲間情報ＩＤ）を付加し、過去の仲間情報ＩＤに基づいた管理を行う。
ここで、プレイヤＩＤ＝“０００００１”のプレイヤＡに注目して、図１１Ｂの説明を続ける。プレイヤＡの過去の仲間情報とは、解除したプレイヤＩＤまたは解除されたプレイヤＩＤの何れかに“０００００１”が含まれている情報であり、過去の仲間情報ＩＤ＝“１００００１”〜“１００００４”の情報がこれに該当する。よって、プレイヤＩＤ＝“０００００２”、“０００００５”、“００００１０”、“００００１２”の各プレイヤは、プレイヤＡの過去の仲間プレイヤである。
後述するように、仲間情報記憶手段５４ａが記憶している過去の仲間情報は、仲間履歴送信手段１０１が過去の仲間プレイヤを表示させるための情報を端末装置３へ送信するときに使用される。
また、仲間情報記憶手段５４ａは、仲間関係にある２人のプレイヤの一方が仲間関係を自主的に解除した場合、当該２人のプレイヤのうち仲間関係を自主的に解除した側のプレイヤと、相手から仲間関係を自主的に解除された側のプレイヤとを区別して記憶することが望ましい。これにより、解除した側のプレイヤの情報のみ、または解除された側のプレイヤの情報のみを、それぞれ抽出することができる。
解除した側と解除された側とを区別して記憶する形態としては、解除した側と解除された側とを区別するための識別情報を過去の仲間情報に付加する形態や、解除した側を記憶する領域と解除された側を記憶する領域とを別に設ける形態などが考えられる。これらの形態の詳細を、以下に説明する。
例えば図１１Ａに示すように、解除した側と解除された側とを区別するための識別情報として、１ビットの「解除者情報」を、過去の仲間情報に付加する。この解除者情報が“１”の場合、図１１Ａ中の「仲間申請をしたプレイヤＩＤ」として登録されているプレイヤＩＤのプレイヤが、仲間関係を自主的に解除したプレイヤであることを示す。また、解除者情報が“０”の場合、図１１Ａ中の「承認したプレイヤＩＤ」として登録されているプレイヤＩＤのプレイヤが、仲間関係を自主的に解除したプレイヤであることを示す。なお仲間解除フラグが“１”の情報が過去の仲間情報であるため、仲間解除フラグが“１”の場合にのみ解除者情報が有効となる（仲間解除フラグが“０”の情報は、現在成立中の仲間情報であるため、解除者情報は無効である）。以下に、具体例を説明する。
ここでは、図１１Ａに記載の仲間情報ＩＤ＝“１”の仲間情報を例に挙げる。仲間情報ＩＤ＝“１”の仲間情報は、仲間解除フラグが“１”に設定されているので、プレイヤＩＤ＝“０００００１”、“０００００２”の２人の仲間関係が既に解除されている過去の仲間情報である。そして、解除者情報が“１”に設定されているので、図１１Ａ中の「仲間申請をしたプレイヤＩＤ」の欄に記載されている“０００００１”のプレイヤＩＤを有するプレイヤＡが、仲間関係を自主的に解除した側のプレイヤである。そして、図１１Ａ中の「承認したプレイヤＩＤ」の欄に記載されている“０００００２”のプレイヤＩＤを有するプレイヤＢが、解除された側のプレイヤである。
また、図１１Ａに記載の仲間情報ＩＤ＝“２”の仲間情報の場合は、仲間解除フラグが“１”なので過去の仲間情報であり、且つ解除者情報が“０”に設定されているので、図１１Ａ中の「承認したプレイヤＩＤ」の欄に記載されている“０００００２”のプレイヤＩＤを有するプレイヤＢが、解除した側のプレイヤである。そして、図１１Ａ中の「仲間申請をしたプレイヤＩＤ」の欄に記載されている“０００００１”のプレイヤＩＤを有するプレイヤＡが、解除された側のプレイヤである。
なお、図１１Ａの例において、解除者情報に代えて、解除した側または解除された側の少なくとも一方のプレイヤＩＤを記憶することにより、両者を区別する形態も考えられる。ただし、プレイヤＩＤを記憶するには複数ビットの情報を記憶する必要がある。これに対して、図１１Ａの「解除者情報」は、１ビットの情報で解除した側と解除された側を明確に区別できるので、好ましい形態である。
また、図１１Ｂに例示するように、現在の仲間情報とは別に過去の仲間情報をデータベースサーバ２等に記憶する形態において、解除したプレイヤのプレイヤＩＤを記憶する領域と、解除されたプレイヤのプレイヤＩＤを記憶する領域とを区別して記憶することにより、両者を明確に区別して記憶することができる。
次に、交流手段５５について説明する。交流手段５５は、プレイヤの端末装置３から、他のプレイヤ（特に、仲間プレイヤ）に対して所定の交流を行う情報を受信し、受信した情報に基づいて、当該プレイヤから当該他のプレイヤに対しての交流処理を実行する機能を備えている。図６に示すように、本実施の形態の交流手段５５は、挨拶手段５５ａ、メッセージ伝達手段５５ｂ、メッセージ記憶部５５ｃ、プレゼント手段５５ｄ、対戦協力手段５５ｅおよび交流履歴記憶手段５５ｆ等を具備する。
挨拶手段５５ａは、各プレイヤの端末装置３から送信された他のプレイヤ宛の挨拶情報を受信して、当該他のプレイヤへ挨拶情報を伝達する機能を有する。また、メッセージ伝達手段５５ｂは、各プレイヤの端末装置３から送信された他のプレイヤ宛のメッセージを受信するとともに、当該メッセージを当該他のプレイヤへ伝達する機能を有する。このメッセージ伝達手段５５ｂは、メッセージ記憶部５５ｃを備えている。
図１２には、メッセージ記憶部５５ｃがデータベースサーバ２に記憶して管理する、受信メッセージに関する情報の一例を示している。このメッセージ記憶部５５ｃは、メッセージを受け取った受信側プレイヤのプレイヤＩＤと対応付けて、送信元のプレイヤＩＤ、メッセージの内容、送信日時などのメッセージに関する情報を、受信側のプレイヤのプレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。また、各メッセージに関する情報には、各メッセージを一意に識別するためのメッセージＩＤが付加されている。図１２の例では、プレイヤＩＤ＝“０００００２”の受信側プレイヤ１人分の受信メッセージに関する情報を示しており、当該プレイヤは、プレイヤＩＤ＝“０００００１”のプレイヤから「プレゼントありがとう！」、プレイヤＩＤ＝“００００３８”のプレイヤから「おはよう！今週のイベント頑張ろう！」、プレイヤＩＤ＝“０００１４５”のプレイヤから「今週もよろしく！」というメッセージをそれぞれ受け取っている。
ここで、プレイヤが、自分の仲間プレイヤに対して、挨拶したりメッセージを送ったりする操作の一例を説明する。例えば、プレイヤが端末装置３を操作してメイン画面中の「仲間リスト」ボタンを選択すれば、端末装置３から仲間リスト要求がゲームサーバ１へ送信される。ゲームサーバ１は、プレイヤの端末装置３からこの要求を受信して、当該プレイヤの仲間リストを表示させる情報を端末装置３へ送信する。これにより端末装置３には、例えば図１４に示すような仲間リスト画面が表示される。この仲間リスト画面には、プレイヤと仲間関係にある仲間プレイヤの情報がリストアップされて表示される。なお、画面に表示しきれない仲間プレイヤの情報については、画面をスクロールするまたは仲間リストの２ページ目以降をゲームサーバ１にリクエストして別画面として表示することができる。
この仲間リスト画面内にはリストアップされた仲間プレイヤ毎の情報表示領域が設けられており、各情報表示領域には、仲間プレイヤのゲーム情報８１（プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等）、当該プレイヤの分身的なキャラクタであるアバター８２、当該プレイヤが所有するリーダーの選手カード８３などとともに、挨拶ボタン８４というオブジェクトも表示される。そして、プレイヤがこの挨拶ボタン８４を選択操作することで、自分の仲間プレイヤに対してゲーム内で仮想的に挨拶することができるようになっている。例えば、プレイヤＡが仲間プレイヤＢの挨拶ボタン８４を選択操作した場合、端末装置３から挨拶情報が送信され、この挨拶情報を受信した挨拶手段５５ａが、仲間プレイヤＢの端末装置３へプレイヤＡから挨拶があったことを伝達する。
ここで、挨拶とは、上記のようにゲーム内で仮想的に行うことができる簡易的な交流の総称であり、エール（応援）を送る、ガッツ（やる気）を送る、ウインクする、微笑む、手を振る等、別の表現を用いた簡易的な交流も含まれる。
プレイヤは、仲間プレイヤに挨拶だけすることもできるが、以下に説明するように、挨拶と同時にメッセージを送ることもできる。
プレイヤの端末装置３における操作により挨拶ボタン８４が選択された場合、当該操作が端末装置３からゲームサーバ１へ伝えられる。その後、ゲームサーバ１からは、例えば図１５に示すメッセージ入力画面のデータが端末装置３へ送信され、端末装置３に当該メッセージ入力画面が表示される。このメッセージ入力画面には、例えば、仲間プレイヤ（図１５の例ではプレイヤＢ）に対して挨拶した旨を示す文章等が表示されるとともに、メッセージ入力領域８５および送信ボタン８６というオブジェクトも表示される。そして、プレイヤは、端末装置３を操作してメッセージ入力領域８５に任意のメッセージを入力し、送信ボタン８６を選択することによって、端末装置３からは仲間プレイヤ宛のメッセージがゲームサーバ１へ送信される。図１５では「プレゼントありがとう」というメッセージをプレイヤが入力した例を示している。なお、データベースサーバ２における記憶容量を考慮して、メッセージ入力領域８５に入力できる文字に制限（例えば全角３０文字以内）を設けてもよい。
なお、メッセージ入力画面には、仲間プレイヤ（この例ではプレイヤＢ）のページへ遷移するためのハイパーリンク８７が表示されており、このリンクを選択することにより当該仲間プレイヤのゲーム情報の詳細が記載されたページを表示できる。また、メッセージ入力画面には、仲間リストへ遷移するためのハイパーリンク８８やメイン画面へ遷移するためのハイパーリンク８９なども表示されており、これらのリンクを選択することにより仲間リストやメイン画面に戻れるようになっている。
このメッセージ入力画面でのプレイヤの操作により端末装置３からメッセージが送信された場合、ゲームサーバ１では、メッセージ伝達手段５５ｂのメッセージ記憶部５５ｃが、端末装置３から受信した仲間プレイヤ宛のメッセージを、当該仲間プレイヤのプレイヤＩＤと対応させてデータベースサーバ２に記憶する（図１２参照）。そして、当該仲間プレイヤの端末装置３がゲームサーバ１へアクセスしたとき、ゲームサーバ１のメッセージ伝達手段５５ｂは、メッセージ、送信元のプレイヤ名、送信時間等を表示させる画面データを端末装置３に送信する。これにより、この画面データを受信したプレイヤの端末装置３にはメッセージ等が表示され、他の仲間から受け取ったメッセージを画面で確認できるようになっている。
このように、本実施の形態のゲームシステムでは、前記図１４および図１５に例示するようなコミュニケーションツールを使用して、仲間同士が何時でもコミュニケーションをとることができるようになっている。
前記図１４および図１５の例では、プレイヤの仲間に対してメッセージを送る例を説明したが、仲間関係にはない他のプレイヤに対しても、挨拶したりメッセージを送ったりすることもできる。例えば、仲間候補リストにリストアップされた仲間ではない他のプレイヤに対して、仲間の場合と同様の操作により、挨拶やメッセージを送ることも可能である。
プレゼント手段５５ｄは、各プレイヤの端末装置３から送信された他のプレイヤ宛のプレゼントの情報を受信して、当該他のプレイヤへプレゼントを届ける機能を有する。プレゼントの対象としては、プレイヤがゲーム内で所有している選手カードや各種アイテムなどが挙げられる。
対戦協力手段５５ｅは、プレイヤ（プレイヤＡとする）の端末装置３から、仲間プレイヤに対して対戦協力を要請する情報を受信し、プレイヤＡのキャラクタ（複数のキャラクタからなるグループやチームでもよい）が他のキャラクタと対戦するときに、仲間プレイヤのキャラクタ（例えば、リーダーの選手カード）を、「助っ人」としてプレイヤＡ側に加担させて対戦協力を実行する機能を有する。このように、仲間プレイヤのキャラクタが助っ人としてプレイヤＡ側に加担して対戦協力することにより、プレイヤＡ側の戦力が向上するので、当該対戦協力がない場合に比べて、プレイヤＡの対戦が有利になる。
なお、プレイヤのキャラクタが他のキャラクタと対戦する場合の「他のキャラクタ」とは、他のプレイヤのキャラクタ（複数のキャラクタからなるグループやチームでもよい）又はゲームサーバ１のＣＰＵが用意したキャラクタ（例えば、各ステージの最後に登場するボスキャラクタ等）のいずれであってもよい。
プレイヤが端末装置３を操作して、助っ人にしたい仲間プレイヤのキャラクタ（または仲間プレイヤ）を選択すれば、端末装置３からは、選択された仲間プレイヤのキャラクタ（または仲間プレイヤ）の情報を含む対戦協力要請情報がゲームサーバ１へ送信される。そして、ゲームサーバ１の対戦協力手段５５ｅは、プレイヤの端末装置３から送信された対戦協力要請情報を受信して、当該プレイヤが選択した仲間プレイヤのキャラクタを助っ人として受け付ける。
図１６Ａに、対戦モードにおけるゲーム画面の一例を示している。このゲーム画面には、プレイヤが指定した対戦相手のチーム（敵軍）の情報９１およびプレイヤのチーム（自軍）の情報９２が表示される。対戦相手のチーム（敵軍）の情報９１としては、例えば、対戦相手のプレイヤ名、アバター、選手カード、戦力に関する情報などが表示される。また、プレイヤのチーム（自軍）の情報９２としては、当該プレイヤのプレイヤ名、アバター、選手カード、戦力に関する情報などが表示される。さらに、このゲーム画面の助っ人表示領域９３には、助っ人として自軍に協力するキャラクタ等の情報が表示されるようになっている。このゲーム画面は、ゲームサーバ１のゲーム画面生成手段５２ｂにより生成されるとともに、ゲーム画面送信手段５２ｃによりプレイヤの端末装置３へ送信されるものであり、端末装置３の表示部３５に表示される。
また、助っ人表示領域９３には、「助っ人を呼ぶ」ボタン９３ａ（またはハイパーリンクが設定された文字列等）が表示され、任意の仲間のキャラクタを助っ人として要請できるようになっている。プレイヤが「助っ人を呼ぶ」ボタン９３ａを選択することにより、例えば図１６Ｂに示す助っ人選択画面に遷移する。この助っ人選択画面には、プレイヤと仲間関係にある仲間プレイヤおよび当該仲間プレイヤが有するキャラクタ（選手カード）がリストアップされて表示される。なお、画面に表示しきれない情報については、画面をスクロールするまたは助っ人選択画面の２ページ目以降をゲームサーバ１にリクエストして別画面として表示することができる。
この助っ人選択画面内にはリストアップされた仲間プレイヤ毎の情報表示領域が設けられており、各情報表示領域には、仲間プレイヤの名前９４ａ、仲間プレイヤのアバター９４ｂ、仲間プレイヤが有する選手カード９４ｃ、選手名９４ｄ、当該選手カードの情報（選手カードに設定されているレベルや攻撃力等）９４ｅなどが表示される。図１６Ｂでは、仲間プレイヤが有する複数の選手カードのうち、リーダーとして設定されている選手カードを助っ人のキャラクタとして選択可能な例を示している。これに限らず、例えば、エース投手や４番打者として設定されている選手カードなどの代表的なキャラクタを、仲間の助っ人として選択可能としてもよい。そして、プレイヤが端末装置３を操作して、例えば仲間プレイヤの名前９４ａに設定されたハイパーリンク表示部分を選択することにより、助っ人にしたい仲間のキャラクタを選択できるようになっている。
例えば、図１６Ｂの助っ人選択画面において、プレイヤＡが端末装置３を操作して仲間プレイヤＢのキャラクタを助っ人として選択した場合、図１６Ｃに例示するゲーム画面に遷移し、助っ人表示領域９３には、プレイヤＢの選手カード９５が助っ人として表示される。また、助っ人表示領域９３には、対戦協力する仲間プレイヤのアバターや対戦協力による戦力アップ情報等も併せて表示される。図１６Ｃの画面例では、対戦協力による戦力アップ情報として「攻撃力＋２００」が表示されている。
なお、プレイヤが仲間の助っ人を選択すれば、ゲームサーバ１において当該仲間の助っ人の情報を当該プレイヤのプレイヤＩＤと対応付けてデータベースサーバ２（記憶装置）に記憶する。よって、プレイヤが仲間の助っ人を選択する操作を行えば、次回の対戦においても、前回選択した仲間のキャラクタが助っ人として設定されるようにすることができる。また、仲間のキャラクタが助っ人として設定されているとき、助っ人表示領域９３には、「助っ人を変更する」ボタン９６（またはハイパーリンクが設定された文字列等）が表示されるようになっている。プレイヤがこのボタン９６を選択することにより、図１６Ｂの助っ人選択画面に遷移し、助っ人にしたい仲間のキャラクタを選択し直すことができるようになっている。
図１６Ａまたは図１６Ｃの対戦モードの画面において、プレイヤが「対戦開始」ボタン９７を選択する操作を行うことにより、プレイヤの端末装置３からは対戦コマンドがゲームサーバ１へ送信され、ゲームサーバ１において対戦処理が実行される。そして、助っ人表示領域９３に仲間のキャラクタが助っ人として表示されているときに「対戦開始」ボタン９７を選択する操作が行われることにより、対戦コマンドと併せて仲間プレイヤに対して対戦協力を要請する情報が、端末装置３からゲームサーバ１に送信される。この場合、仲間プレイヤのキャラクタを助っ人としてプレイヤ側に加担させる対戦協力が実行されることになる。
つぎに、交流履歴記憶手段５５ｆについて説明する。交流履歴記憶手段５５ｆは、各プレイヤの交流履歴をデータベースサーバ２（記憶装置）に記憶する。交流手段５５において、プレイヤから他のプレイヤに対しての交流処理が実行されたとき、交流履歴記憶手段５５ｆは、交流履歴として、例えば図４３に示すように、交流情報ＩＤ、交流をしたプレイヤＩＤ、交流相手のプレイヤＩＤ、交流種別、交流処理実行時の時間情報等を記憶する。交流種別とは、挨拶、メッセージ、プレゼント、対戦協力等の、具体的な交流の内容を示すものである。交流処理実行時の時間情報としては、年、月、日、時、分、秒等の時間情報を記憶するが、ここで記憶する時間の単位は任意に設定できる。
なお、交流手段５５が実行する交流処理の対象となる交流は、上述の挨拶、メッセージの送信、プレゼント、協力対戦の助っ人依頼に限定されるものではなく、仲間のプレイヤ同士で行われる様々な交流を含めることができる。交流のその他の例としては、合同練習などがある。合同練習とは、交流の一種であり、プレイヤがゲーム内で仮想的に仲間プレイヤとともに行う練習である。合同練習を希望するプレイヤは、仲間プレイヤを指定して合同練習を申込み、当該仲間プレイヤが所定期間内に（例えば、申込みがあったその日のうちに）ゲームにアクセス（ログイン）した場合に合同練習が成立する。
次に、仲間履歴送信手段１０１について説明する。仲間履歴送信手段１０１は、プレイヤが操作する端末装置３からの要求に応じて、仲間情報記憶手段５４ａに記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置３へ送信する機能を有する。
例えば、プレイヤが端末装置３を操作してメイン画面中の「過去の仲間リスト」ボタンを選択すれば、端末装置３から過去の仲間リスト要求がゲームサーバ１へ送信される。仲間履歴送信手段１０１は、プレイヤの端末装置３からこの要求を受信して、当該プレイヤの過去の仲間リストを表示させる情報（過去の仲間リストの画面データ）を端末装置３へ送信する。仲間履歴送信手段１０１が送信した情報を受信した端末装置３には、例えば図１７に示すような過去の仲間リスト画面が表示される。この過去の仲間リスト画面には、プレイヤと過去に仲間関係にあった仲間プレイヤの情報がリストアップされて表示される。なお、画面に表示しきれない過去の仲間プレイヤの情報については、画面をスクロールするまたはリストの２ページ目以降をゲームサーバ１にリクエストして別画面として表示することができる。
後述するように、図１７に示す過去の仲間リスト画面中にリストアップされる過去の仲間プレイヤは、当該画面を表示している端末装置３を有するプレイヤが過去に自主的に仲間解除した仲間プレイヤであってもよい。
この過去の仲間リスト画面内には、リストアップされた過去の仲間プレイヤ毎の情報表示領域が設けられており、各情報表示領域には、過去の仲間プレイヤの現在のゲーム情報２０１（プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等）、当該プレイヤの分身的なキャラクタであるアバター２０２、当該プレイヤが所有するリーダーの選手カード２０３などとともに、復活申請ボタン２０４というオブジェクトも表示される。そして、プレイヤが仲間関係を復活させたい過去の仲間プレイヤを選択する（この例では、過去の仲間プレイヤの復活申請ボタン２０４を選択する）操作を行うことにより、当該操作の情報が端末装置３からゲームサーバ１へと送信される。この操作の情報をプレイヤの端末装置３から受信した仲間復活申請手段１０２は、当該プレイヤから選択された過去の仲間プレイヤへの仲間関係復活の申請処理を実行するようになっている。
図１７に示すように、過去の仲間リストの中に、リストアップされた過去の仲間プレイヤの各々の現在のゲームレベル（プレイヤのレベル、所属リーグのレベル等）を表示させることが望ましい。これを実現するゲームサーバ１の構成は次の通りである。すなわち、ゲームレベル記憶手段（図５に示すレベル情報記憶手段５１ｂ等）が、各プレイヤのゲームレベルを記憶装置（データベースサーバ２等）に記憶している。そして、仲間履歴送信手段１０１は、プレイヤが操作する端末装置３からの要求に応じて、仲間情報記憶手段５４ａに記憶されている当該プレイヤの過去の仲間情報および前記ゲームレベル記憶手段に記憶されている当該プレイヤの過去の仲間プレイヤの現在のゲームレベルをそれぞれ読み出し、当該プレイヤの過去の仲間プレイヤを表示させるための情報とともに、当該過去の仲間プレイヤの現在のゲームレベルを表示させるための情報を、前記端末装置３へ送信する。なお、「ゲームレベル」の詳細については、後述する。
これにより、プレイヤは、端末装置３の表示された過去の仲間プレイヤの現在のゲームレベルを確認しながら、もう一度、仲間関係を築くか否かを判断することができる。例えば、以前はあまりゲームにアクセスしていなかった他のプレイヤＸとの仲間関係を解除したが、当該プレイヤＸの現在のゲームレベルは以前よりも格段に高くなっていることが確認できた場合、当該プレイヤＸともう一度仲間になってもよいという判断ができる。
また、プレイヤが仲間復活申請を行う際に、相手に対するメッセージを添付することができるようにする（すなわち、メッセージ付きの仲間復活申請を可能とする）ことが望ましい。例えば、プレイヤが復活申請ボタン２０４を選択する操作を行うことにより、ゲームサーバ１からは、図１５に類似したメッセージ入力画面のデータが端末装置３へ送信されるようにする。このようなメッセージ入力画面で、プレイヤが仲間復活申請の相手に対するメッセージを入力してゲームサーバ１へ送信すれば、メッセージ付きの仲間復活申請ができる。なお、メッセージの添付は任意事項であり、メッセージを添付しない場合でも仲間復活申請は可能である。
図１９には、仲間復活申請を管理するための記憶情報の一例を示している。仲間関係復活の申請処理を実行する仲間復活申請手段１０２は、図１９に例示するように、仲間情報を管理するための仲間情報ＩＤと対応づけて、復活申請をしたプレイヤのプレイヤＩＤをデータベースサーバ２に登録する。図１９における仲間情報ＩＤ＝“１”の例では、プレイヤＩＤ＝“０００００１”のプレイヤＡが復活申請した例を示している。そして、仲間復活申請手段１０２は、申請相手の過去の仲間プレイヤＢの端末装置３に対して、プレイヤＡから復活申請があったことを表示させるための情報を送信する。なお、メッセージ付き仲間復活申請であった場合には、メッセージ伝達手段５５ｂと協働して、仲間復活申請手段１０２が申請者からのメッセージも併せて送信する。なお、これらの送信は、プレイヤＡが復活申請をした後、過去の仲間プレイヤＢの端末装置３がゲームサーバ１に最初にアクセスしたときに行われる。
仲間復活申請手段１０２が送信した情報を受信した過去の仲間プレイヤＢの端末装置３では、例えば、図１８に示すような承認・拒否選択画面が表示される。この画面には、仲間復活申請をしたプレイヤＡの現在のゲーム情報２１１（プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等）、当該プレイヤのアバター２１２、当該プレイヤが所有するリーダーの選手カード２１３などとともに、承認ボタン２１４、拒否ボタン２１５というオブジェクトも表示される。また、メッセージ付き仲間復活申請であった場合には、申請者からのメッセージも併せて表示される。ここで、プレイヤが拒否ボタン２１５を選択することにより、仲間関係の復活を拒否することもできる。一方、プレイヤＢがプレイヤＡとの仲間関係の復活を承認する場合、承認ボタン２１４を選択する操作を行うことにより、当該操作の情報がプレイヤＢの端末装置３からゲームサーバ１へと送信される。この操作の情報を受信したゲームサーバ１の仲間管理手段５４は、プレイヤＢからの承認を受け付け、仲間関係復活処理を実行するようになっている。
仲間関係復活処理を実行する仲間管理手段５４は、例えば図１９に示すように、仲間情報を管理するための仲間情報ＩＤと対応づけて記憶されている仲間解除フラグを“０”に設定する（図１９中の仲間情報ＩＤ＝“２２”を参照）。また、このとき、復活承認したプレイヤのプレイヤＩＤおよび仲間関係の復活時間（復活日等）の情報を併せてデータベースサーバ２に記憶していてもよい。
〔ゲームシステムの動作〕
上記の構成において、本発明の実施の形態に係るゲームシステムの動作例を、図２０のフローチャートを参照しながら以下に説明する。図２０は、プレイヤが端末装置３を操作してゲームサーバ１にアクセスしてゲームサービスを受けるときの、端末装置３およびゲームサーバ１の処理の流れを示すものである。
プレイヤがゲームサービスを受ける場合、先ず、端末装置３の操作入力部４０を操作してウェブブラウザを起動する（Ｓ１１）。その後、プレイヤは、ゲームサーバ１が管理するゲームサイトにアクセスする操作を行い、これにより、端末装置３からゲームサーバ１へアクセスリクエストが送信される（Ｓ１２）。このとき、ゲームサーバ１は、端末装置３からのアクセスに対するログイン認証を行い（Ｓ２１）、ゲームサービスの利用登録がなされているプレイヤからのアクセスであることを確認する。その後、ゲームサーバ１は、ＨＴＭＬ等で記述されたメイン画面データを端末装置３に送信する（Ｓ２２）。なお、メイン画面とは別のトップ画面がある場合は、まずトップ画面を送信してもよい。そして、メイン画面データを受信した端末装置３では、ウェブブラウザが当該データを解釈し、メイン画面を表示部３５に表示させる（Ｓ１３）。
図１３に例示するように、メイン画面には、プレイヤのチーム名７０、プレイヤが所有する選手カードの中からリーダーとして選択された選手カード７１の画像、プレイヤのゲーム情報７２（プレイヤのレベル、行動力ポイント、運営コスト、強化ポイント、交流ポイント、所有する選手カードの数、仲間人数など）が表示される。また、スカウト、オーダー、強化、抽選、試合の各モードを選択するためのボタン群７３なども表示される。さらに、このメイン画面には、端末装置３の方向キーやタッチパネル等を操作して画面をスクロールさせることによって、図示しない各種メニューボタン、仲間の動き情報、他のプレイヤからのメッセージなど、様々なオブジェクトや情報が表示されるようになっている。
ここでプレイヤが、画面に表示されている選択可能なボタン等のオブジェクトやハイパーリンクを選択する操作をすると、当該操作に応じた画面のリクエストが端末装置３からゲームサーバ１へ送信される（Ｓ１４）。このリクエストを受信したゲームサーバ１は、プレイヤの操作に応じた演算処理やデータ処理を行ってゲームを実行し（Ｓ２３）、実行結果を反映させたゲーム画面データを端末装置３へ送信する（Ｓ２４）。そして、画面データを受信した端末装置３では、ウェブブラウザが当該データを解釈し、ゲーム画面を表示部３５に表示させる（Ｓ１５）。
以降は、プレイヤの端末装置３においては前記のＳ１４およびＳ１５が繰り返され、ゲームサーバ１においては前記のＳ２３およびＳ２４が繰り返され、これにより、端末装置３の画面に表示されている選択可能なボタン等をプレイヤが選択する度に、端末装置３のゲーム画面が次々と切り替わり、ゲームを進行させることができる。
その後、プレイヤが端末装置３を操作してゲーム画面を閉じた場合（Ｓ１６）、ゲームサーバ１はログアウト処理を行う（Ｓ２５）。例えば、プレイヤがウェブブラウザを閉じた場合、ゲームサーバ１はセッションタイムアウト後にログアウト処理を行う。
ところで、本ゲームシステムにおいては、プレイヤがゲームサーバ１からログアウトした場合であっても、ゲームサーバ１側で当該プレイヤのゲーム情報を読み出してゲームを進行させることができる。例えば、ログアウトしているプレイヤのチームに対して、ログインしている他のプレイヤが対戦（個別対戦）を仕掛けてくることもある。この場合も、ゲームサーバ１のゲーム進行手段５２は、プレイヤがログインしているか否かに依らずに、各プレイヤのゲーム情報をデータベースサーバ２から読み出して対戦を実行し、その実行結果を反映させて各プレイヤのゲーム情報を更新する。また、リーグ戦モードでは、プレイヤによる端末装置３の操作なしに、ゲームサーバ１のゲーム進行手段５２が、各プレイヤのゲーム情報をデータベースサーバ２から読み出して、自動でリーグ戦の試合を実行する。このように、プレイヤがゲームサーバ１からログアウトしているときに実行された対戦の結果は、その後、プレイヤがゲームサーバ１にアクセスしたときに画面で確認することができる。
〔ゲーム管理装置の動作〕
次に、本発明の実施の形態に係るゲーム管理装置のより詳細な動作例を、図２１ないし図２４のフローチャートを参照しながら説明する。図２１は、ある１人のプレイヤを対象としたゲームサーバ１の処理の流れを示すものであり、ゲームサーバ１が管理している各々のプレイヤに対して同様の処理が行われる。
図２１に示すように、ゲームサーバ１の認証手段５３は、プレイヤの端末装置３からアクセス要求を受けたとき（Ｓ３１でＹＥＳ）、端末装置３から送信されてきたログインＩＤ・パスワード、または携帯電話端末の個体識別番号等に基づいて、アクセスを許可するか否かを判断するログイン認証を行う（Ｓ３２）。ここで、アクセスを許可しない場合（Ｓ３２でＮＯ）、ゲームサーバ１は、端末装置３にゲームサービスの利用登録を促す画面データを送信する（Ｓ３３）。一方、アクセスを許可する場合（Ｓ３２でＹＥＳ）、アクセス情報（ログ）を記憶する（Ｓ３４）。
そして、ゲームサーバ１は、アクセスを許可したプレイヤの端末装置３に、メイン画面データ（またはトップ画面データ）を送信する（Ｓ３５）。その後、プレイヤの端末装置３から送信されてくるプレイヤのゲーム操作に応じた画面リクエストを受信すると（Ｓ３６でＹＥＳ）、ゲーム実行手段５２ａは、当該画面リクエストに応じた演算処理やデータ処理を行ってゲームを実行する（Ｓ３７）。
その後、ゲームサーバ１はゲームの実行によりプレイヤのゲーム情報を更新する必要があるか否かを判断し（Ｓ３８）、更新の必要がある場合（Ｓ３８でＹＥＳ）、データベースサーバ２に記憶されているプレイヤのゲーム情報を更新する（Ｓ３９）。例えば、プレイヤのゲーム操作が他のプレイヤとの個別対戦を行う操作であった場合、当該対戦が実行された結果、試合結果の情報、運営コスト、強化ポイント、アイテム等のプレイヤのゲーム情報が更新されることになる。一方、例えば、プレイヤのゲーム操作がリーグ戦の結果確認の操作であった場合、当該操作に応じたゲームの実行処理としてはリーグ戦の結果情報をデータベースサーバ２から読み出すデータ処理だけであって、当該処理の前後でプレイヤのゲーム情報に変化はなく、よってプレイヤのゲーム情報を更新する必要はない（Ｓ３８でＮＯ）。
その後、ゲーム画面生成手段５２ｂがゲームの実行結果を反映させたゲーム画面データを生成し（Ｓ４０）、ゲーム画面送信手段５２ｃが当該ゲーム画面データをプレイヤの端末装置３へ送信する（Ｓ４１）。その後、プレイヤの端末装置３がログアウトしたか否かが判断され（Ｓ４２）、端末装置３がログアウトするまで、前記Ｓ３６〜Ｓ４１の処理が繰り返されることで、ゲームが進行していく。
次に、図２２を参照して、ゲームサーバ１における仲間解除時の処理例について説明する。図２２のフローチャートは、仲間関係が成立している２人のプレイヤを対象としたゲームサーバ１の処理の流れを示すものであり、ゲームサーバ１が管理している全ての仲間同士のペアに対して同様の処理が行われることになる。
プレイヤは、自分の仲間プレイヤとの仲間関係をいつでも自主的に解除することができる。例えば、図１４に示す仲間リストから仲間関係を解除したい仲間プレイヤを選択して所定の操作を行うことにより、当該仲間プレイヤとの仲間関係を解除できる。仲間関係の成立時とは異なり、その解除には相手側の承認は不要である。仲間解除の操作が行われた場合、プレイヤの端末装置３からゲームサーバ１へ仲間解除要求が送信される。
図２２に示すように、ゲームサーバ１がプレイヤの端末装置３から仲間解除要求を受信したとき（Ｓ５１でＹＥＳ）、仲間管理手段５４は仲間関係の解除処理を実行する（Ｓ５２）。例えば、仲間管理手段５４の仲間情報記憶手段５４ａが、図１１Ａに示すように、仲間関係が解除された２人の仲間情報に仲間解除フラグを立てる。これにより、２人の仲間関係が解除された後も、当該２人のプレイヤを関係付けた過去の仲間情報が保持される（Ｓ５３）。
その後、仲間管理手段５４は、図１１Ａに例示する解除者情報を設定して、仲間関係が解除された２人のうち何れのプレイヤが自主的に仲間を解除したのかを識別できるようにする（Ｓ５４）。このＳ５４の処理は、省くこともできる。
なお、仲間関係の解除処理の他の例としては、仲間関係が解除された２人の仲間情報を削除し（Ｓ５２）、図１１Ｂに示すように仲間関係を自主的に解除した側と解除された側の２人のプレイヤを関係付けた過去の仲間情報を新規に記憶してもよい（Ｓ５３およびＳ５４）。
その後、ゲームサーバ１は、仲間関係が解除された２人のプレイヤの端末装置３に対して、仲間関係解除の旨を報知するための情報（解除の旨を含む画面データ等）を送信し、当該２人のプレイヤに仲間関係解除の事実を報知する（Ｓ５５）。報知の例としては、ゲーム画面の中に仲間関係解除の旨を表示することの他に、音声による報知や画面表示と音声とを併用した報知も考えられる。音声による報知は、ゲームサーバ１からプレイヤの端末装置３へ送信する画面データ（ＨＴＭＬデータ等）に音声データを含ませることにより実現できる。なお、ゲームサーバ１が、仲間関係の解除を報知するためには、プレイヤの端末装置３がゲームサーバ１にアクセスしている必要がある。仲間関係を自主的に解除した側のプレイヤの端末装置３は、解除時においてゲームサーバ１にアクセスしているので直ぐに報知できるが、解除された側のプレイヤの端末装置３はゲームサーバ１にアクセスしているとは限らない。よって、ゲームサーバ１は、仲間関係の解除処理を実行した後、仲間関係が解除された側のプレイヤの端末装置３がゲームサーバ１に最初にアクセスしたときに、Ｓ５５の報知処理を実行することになる。
次に、図２３を参照して、仲間関係の復活について説明する。図２３は、プレイヤＡがプレイヤＢに対して仲間復活申請を行う例を示している。また、プレイヤＡの端末装置を「端末装置３Ａ」、プレイヤＢの端末装置を「端末装置３Ｂ」としている。
プレイヤは、自分の過去の仲間リストをいつでも端末装置３の画面上で確認することができる。例えば、プレイヤＡが端末装置３Ａを操作してメイン画面中の「過去の仲間リスト」ボタンを選択すれば、端末装置３Ａから過去の仲間リスト要求がゲームサーバ１へ送信される（Ｓ６１）。ゲームサーバ１ではこの要求を受信し（Ｓ７１）、仲間情報記憶手段５４ａが記憶している、プレイヤＡの過去の仲間情報を読み出す（Ｓ７２）。そして、仲間履歴送信手段１０１は、プレイヤＡの過去の仲間リストを表示させる情報（過去の仲間リストの画面データ）を端末装置３Ａへ送信する（Ｓ７３）。この仲間履歴送信手段１０１が送信した情報を受信した端末装置３Ａには、例えば図１７に示すような過去の仲間リスト画面が表示されることになる（Ｓ６２）。これにより、プレイヤＡは、端末装置３Ａの画面上で過去の仲間プレイヤを確認しながら、仲間関係を復帰したい相手を検討することができる。
そして、過去の仲間リストが表示されている端末装置３ＡにてプレイヤＡが仲間関係を復活させたい過去の仲間プレイヤを選択する操作を行うことにより（Ｓ６３）、当該操作の情報が端末装置３Ａからゲームサーバ１へと送信される。なお、この操作の際、プレイヤＡがプレイヤＢに対するメッセージを入力すれば、当該メッセージも端末装置３Ａからゲームサーバ１へと送信され、メッセージ付き仲間復活申請とすることができる。
この例では、プレイヤＡが過去の仲間プレイヤＢを選択する操作を行ったものとする。ゲームサーバ１ではこの操作の情報を受信し（Ｓ７４）、仲間復活申請手段１０２がプレイヤＡからプレイヤＢへの仲間関係復活の申請処理を実行する（Ｓ７５）。例えば、仲間復活申請手段１０２は、図１９に例示するように、プレイヤＡ・Ｂを関係付けた過去の仲間情報（仲間情報ＩＤ＝“１”の情報）と対応付けて、復活申請をしたプレイヤＡのプレイヤＩＤ＝“０００００１”を記憶する。さらに、仲間復活申請手段１０２は、プレイヤＡが復活申請をした後、プレイヤＢの端末装置３Ｂがゲームサーバ１に最初にアクセスしたときに、端末装置３Ｂに対してプレイヤＡから復活申請があったことを表示させるための情報を送信する。なお、メッセージ付き仲間復活申請の場合には、メッセージ伝達手段５５ｂと協働して、仲間復活申請手段１０２が、プレイヤＡからのメッセージも併せて端末装置３Ｂへ送信する。
仲間復活申請手段１０２が送信した情報を受信したプレイヤＢの端末装置３Ｂでは（Ｓ８１）、例えば図１８に示すような承認・拒否選択画面が表示される。なお、メッセージ付き仲間復活申請の場合には、併せてプレイヤＡからのメッセージも表示される。プレイヤＢは、プレイヤＡからの仲間復活申請を承認することも拒否することも可能であるが、図２３では承認する場合の動作を例示している。
プレイヤＢが承認ボタン２１４を選択する操作を行うことにより（Ｓ８２）、当該操作の情報がプレイヤＢの端末装置３からゲームサーバ１へと送信される。この操作の情報を受信したゲームサーバ１では（Ｓ７６）、仲間管理手段５４がプレイヤＡとＢとの仲間関係の復活処理を実行する（Ｓ７７）。例えば、仲間管理手段５４は、プレイヤＡとＢとを関係付けた仲間情報の仲間解除フラグを“０”に設定する。このとき、図１９に示す復活承認したプレイヤＩＤおよび復活時間（復活日等）の情報を記憶していてもよい。
その後、ゲームサーバ１は、仲間関係が復活した２人のプレイヤＡ・Ｂの端末装置３Ａ・３Ｂに対して、仲間関係が復活した旨を報知するための復活通知（復活の旨を含む画面データ等）を送信する（Ｓ７８）。この復活通知を受信した端末装置３Ａ・３Ｂでは（Ｓ６４、Ｓ８３）、プレイヤＡ・Ｂ間の仲間関係が復活した旨が表示される。
上記のように、本実施の形態のゲームサーバ１を適用することにより、プレイヤは、自分の端末装置３に過去の仲間リストを表示させることができ、所望の相手に対して簡単に仲間復活申請を行うことができるようになっている。これにより、プレイヤは、過去の仲間プレイヤと仲間関係を再構築する機会が与えられる。よって、以下に例示するような従来ではできなかったことや新たなゲームの楽しみ方ができるようになる。
例えば、プレイヤが、仲間であった相手との仲間関係を誤操作等により誤って解除してしまった場合、その後、同じ相手と仲間関係を再構築する機会が得られる。
また、何らかの理由（例えば、海外出張や受験に専念等）でプレイヤが一時的に暫くゲームから離れる必要が生じた場合、次のような対応が可能である。すなわち、ゲームから離れている期間中は仲間プレイヤとの仲間関係を解消し、その後、ゲームを再開するときに、過去の仲間プレイヤに仲間復活申請を行い、仲間関係を復活させる。この場合、プレイヤが仲間プレイヤとの仲間関係を解消する前に、当該相手にメッセージでその理由および後日復活申請を行う旨を伝えておき、相手にそれを納得してもらえば、仲間復活申請に対して相手から承認が得られ易く、仲間関係の復活を円滑に行うことができるようになる。この対応は、特に仲間数に上限（例えば５０人）が設定されているゲームにおいて有効である。すなわち、もしプレイヤがゲームから離れている間も仲間関係を維持し続ければ、仲間プレイヤの限られた仲間枠を無駄に使ってしまうことになり兼ねない。そこで、プレイヤがゲームから離れている期間中の仲間関係を解消すれば、仲間プレイヤは空いた仲間枠を使って、他のプレイヤと交流等を楽しむことができる。
また、仲間数に上限が設定されているゲームにおいて、次のようなことも可能になる。すなわち、仲間数が上限に達しているプレイヤが、新しい他のプレイヤＹと仲間になるために、仲間プレイヤＸとの関係を一旦解除する。その後、プレイヤＹと思うような交流ができなかったような場合には、プレイヤＹとの関係を解除した上で、プレイヤＸに仲間復活申請を行い、仲間関係を復活させる。このように、本実施の形態のゲームサーバ１を適用すれば、プレイヤは、限られた仲間枠を有効に使った新なゲームの楽しみ方ができる。
ところで、仲間復活申請を可能としたことにより、仲間関係を自主的に解除した側のプレイヤが、折角解除した過去の仲間プレイヤから、後日、望まないかたちで仲間復活申請を受ける可能性がある。これを回避するための構成を以下に説明する。
仲間情報記憶手段５４ａは、図１１Ａまたは図１１Ｂに例示するように、仲間関係を自主的に解除した側のプレイヤと、相手から仲間関係を自主的に解除された側のプレイヤと、を解除者情報等で区別して記憶している。そして、仲間履歴送信手段１０１は、プレイヤが操作する端末装置３からの要求に応じて、仲間情報記憶手段５４ａに記憶されている当該プレイヤの過去の仲間情報のうち当該プレイヤが仲間関係を自主的に解除した場合の情報を読み出し、当該プレイヤが仲間関係を自主的に解除した過去の仲間プレイヤを表示させるための情報を当該端末装置３へ送信するようになっている。この構成のゲームサーバ１における仲間履歴送信処理を、図２４を参照して以下に説明する。
ここでは、プレイヤＡが操作する端末装置３からの要求に応じて、図１１Ａに示す仲間情報から必要な情報を抽出して処理するゲームサーバ１の動作例を説明する。プレイヤＡが端末装置３を操作して、例えばメイン画面中の「過去の仲間リスト」ボタンを選択すれば、プレイヤＡの端末装置３から過去の仲間リスト要求がゲームサーバ１へ送信される。この要求をゲームサーバ１が受信すれば（Ｓ９１でＹＥＳ）、先ず、図１１Ａに示す仲間情報から対象となるプレイヤＡ（プレイヤＩＤ＝“０００００１”）の仲間情報を抽出する（Ｓ９２）。すなわち、図１１Ａに示す仲間情報の中から、仲間申請をしたプレイヤＩＤまたは承認したプレイヤＩＤの何れかに“０００００１”が含まれている仲間情報を抽出する。このステップＳ９２により、仲間情報ＩＤ＝“１”、“２”、“３”、“２２”、“２３”、“８１”の仲間情報が抽出される。さらに、ゲームサーバ１は、ステップＳ９２で抽出した仲間情報のうち、仲間解除フラグが“１”に設定されている過去の仲間情報を抽出する（Ｓ９３）。このステップＳ９３により、仲間情報ＩＤ＝“１”、“２”、“２２”、“２３”の仲間情報が抽出される。なお、前記ステップＳ９２およびＳ９３は、データベースの複数条件検索により同時に実行することもできる。
さらに、ゲームサーバ１は、ステップＳ９３で抽出した過去の仲間情報のうち、プレイヤＡが自主的に解除した過去の仲間情報を抽出する（Ｓ９４）。すなわち、プレイヤＡのプレイヤＩＤ＝“０００００１”が、「仲間申請をしたプレイヤＩＤ」の欄に含まれる場合には、「解除者情報」が「１」の情報を抽出する。また、プレイヤＡのプレイヤＩＤ＝“０００００１”が、「承認をしたプレイヤＩＤ」の欄に含まれる場合には、「解除者情報」が「０」の情報を抽出する。このＳ９４により、仲間情報ＩＤ＝“１”、“２３”の仲間情報が抽出される。このステップＳ９４も、データベースの複数条件検索により、Ｓ９２およびＳ９３と同時に実行することもできる。
その後、ゲームサーバ１は、ステップＳ９４で抽出した過去の仲間情報の中から、プレイヤＡの相手の過去の仲間のプレイヤＩＤをリストアップする（Ｓ９５）。このステップＳ９５により、プレイヤＡが自主的に解除した過去の仲間プレイヤのプレイヤＩＤとして、“０００００２”および“００００１２”がリストアップされる。
その後、仲間履歴送信手段１０１は、ステップＳ９５でリストアップしたプレイヤＩＤに基づいて、プレイヤＡが仲間関係を自主的に解除した過去の仲間プレイヤのみからなる過去の仲間リスト画面データを生成し、それをプレイヤの端末装置３に送信する（Ｓ９６）。
これにより、プレイヤの端末装置３には、当該プレイヤが自ら仲間関係を解除した過去の仲間プレイヤのみが表示され、当該プレイヤが相手から仲間関係を解除された場合の相手情報は表示されないことになる。よって、仲間関係を解除された側のプレイヤは、解除した側のプレイヤに対する仲間復活申請ができない。これにより、解除した側のプレイヤが、解除された側のプレイヤから、望まない仲間復活申請を受けるといった事態を効果的に回避できる。
ところで、良心的な仲間プレイヤは、仲間関係の解除前に、その理由をメッセージで伝えると考えられる。もし、理由も言わないで、突然、相手から仲間関係が解除された場合、自分を解除した相手に対して、仲間復活申請をしようとは思わないプレイヤが多いと考えられる。このような事情を考慮すると、プレイヤにとっては、自分を解除した相手が省かれた状態で過去の仲間プレイヤが端末装置３に表示されることにより、所望の相手を見つけ易くなるという効果も期待できる。
〔ゲーム管理装置の他の構成例〕
次に、仲間復活申請を受けたプレイヤの承認を促進し、仲間関係の再構築がされ易いようにすることができるゲーム管理装置の構成について、図２５の機能ブロック図等を参照しながら説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。
本実施の形態のゲームサーバ１（ゲーム管理装置）は、図４に示した各手段に加えて、仲間成立ポイント付与手段１０３をさらに備えている。この仲間成立ポイント付与手段１０３は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。仲間成立ポイント付与手段１０３は、２人のプレイヤ間で仲間関係が成立したときに、ボーナスとして少なくとも承認した側のプレイヤに対して、所定の仲間成立ポイントを付与する機能を有する。すなわち、仲間成立ポイント付与手段１０３は、仲間申請側および承認側の両方のプレイヤにそれぞれ仲間成立ポイントを付与してもよいし、承認側のプレイヤのみに仲間成立ポイントを付与してもよい。本実施の形態では、仲間申請側および承認側の両方のプレイヤに所定の仲間成立ポイントを付与する構成について説明する。
本実施の形態では、仲間成立ポイント付与手段１０３が、新規で仲間関係が成立した２人のプレイヤに、例えば３ポイントずつ仲間成立ポイントを付与するようになっている。ここで、仲間成立ポイントは、例えば、上述の行動力ポイントまたは運営コストの最大値を高めるポイントとして利用できるようになっている。仲間関係が成立した２人のプレイヤに仲間成立ポイントが付与されたことにより、ゲーム情報管理手段５１の所有ポイント記憶手段５１ｄが記憶している当該２人のポイントは更新される。
なお、何れか一方のプレイヤにより仲間関係が解除された場合には、仲間成立ポイントの増減を回避するため、仲間関係成立時に当該２人のプレイヤに対して付与された仲間成立ポイントと同じ３ポイントがゲーム情報管理手段５１により削減されるようにしてもよい。仲間関係が解除されたときにポイントを削減するか否かは任意に設定できる。
また、本実施の形態の仲間成立ポイント付与手段１０３は、仲間復活申請を承認した過去の仲間プレイヤに対して付与するポイントを、復活申請ではなく通常の仲間申請を承認したプレイヤに対して付与するポイントよりも高くするようになっている。一例を挙げると、仲間成立ポイント付与手段１０３は、通常の仲間申請を承認したプレイヤには３ポイント、仲間復活申請を承認した過去の仲間プレイヤに対しては５ポイントを、それぞれ付与する。なお、上記の各ポイントの値はこれらに限らず、通常の仲間申請を承認した場合より仲間復活申請を承認した場合の方が付与されるポイントが多いという条件を満たせば、任意の値に設定できる。
本実施の形態のゲームサーバ１における仲間成立ポイント付与処理の例を、図２６を参照して以下に説明する。
プレイヤが承認の操作を行った場合（Ｓ１０１）、その承認が仲間復活申請に対する承認であるか否かが判定される（Ｓ１０２）。ここで、その承認が仲間復活申請ではなく通常の仲間申請に対する承認の場合（Ｓ１０２でＮＯ）、仲間管理手段５４は、通常の仲間関係の成立処理を実行する（Ｓ１０３）。この場合、仲間成立ポイント付与手段１０３は、承認した側のプレイヤに対して、例えば３ポイントの仲間成立ポイントを付与する（Ｓ１０４）。
一方、前記の承認が仲間復活申請に対する承認の場合（Ｓ１０２でＹＥＳ）、仲間管理手段５４は、仲間関係復活処理を実行する（Ｓ１０５）。この場合、仲間成立ポイント付与手段１０３は、承認した側のプレイヤに対して、例えば５ポイントの仲間成立ポイントを付与する（Ｓ１０６）。
Ｓ１０４またはＳ１０６の処理の後、仲間成立ポイント付与手段１０３は、申請した側のプレイヤに対して、例えば３ポイントの仲間成立ポイントを付与する（Ｓ１０７）。
このように、本実施の形態では、通常の仲間申請を承認した場合より仲間復活申請を承認した場合の方がより多くのポイントを付与することにより、仲間復活申請を受けたプレイヤの承認を促進している。これにより、仲間関係が復活され易くなり、本ゲームサーバ１が有する仲間関係を復活させる機能の実効性を高めている。
ところで、仲間復活申請を承認した方が、通常の仲間申請を承認するより多くのポイントが得られる場合、仲間同士でポイントの獲得だけを狙って仲間関係の解除と復活とを短期間で繰り返すという不適正な事態が生じる可能性がある。例えば、仲間同士でメッセージのやり取りをしながら、ポイント狙いの仲間関係の復活の繰り返しを画策することも起こり得る。そこで、このような事態を回避するための構成について、以下に説明する。
図２５に示すように、ゲームサーバ１は、復活時間記憶手段１０４および再復活制限手段１０５をさらに備えている。これらの手段は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。
復活時間記憶手段１０４は、仲間復活申請手段１０２が実行した仲間復活申請処理による申請をプレイヤの過去の仲間プレイヤが承認して仲間関係が復活した場合、仲間関係の復活時間の情報を記憶手段（データベースサーバ２）に記憶する機能を有する。ここで、復活時間としては、年、月、日、時、分、秒等の時間情報を記憶するが、ここで記憶する時間の単位は任意に設定できる。例えば、図１９に示すように、復活時間記憶手段１０４は、仲間関係が復活した２人のプレイヤを関係付けた仲間情報ＩＤと対応付けて、復活時間（復活日等）をデータベースサーバ２に記憶する。
また、再復活制限手段１０５は、復活時間記憶手段１０４が記憶した２人のプレイヤの復活時間から所定期間（例えば３か月）が経過するまでは、当該２人のプレイヤ間での仲間関係の再度の復活を許可しないという機能を有する。例えば、２人のプレイヤが仲間関係を復活させた後、所定期間が経過する前に、何れか一方のプレイヤにより仲間復活申請の操作が行われても、その申請を受け付けずに、仲間復活申請処理が実行されないようにする。そして、前記の所定期間が経過した後は、仲間復活申請の操作が行われたときに仲間復活申請処理が実行されるようにする。あるいは、前記の所定期間が経過する前であっても仲間復活申請処理については実行されるようにするが、前記の所定期間が経過する前にプレイヤにより仲間復活申請に対する承認の操作が行われた場合には、その承認を受け付けずに、仲間復活処理が実行されないようにする。そして、前記の所定期間が経過した後は、仲間復活申請に対する承認の操作が行われたときに仲間復活処理が実行されるようにする。
ここで、仲間関係の復活後に再復活が禁止される期間である前記の「所定期間」としては、任意の期間を設定可能である。例えば、所定期間を一定の期間（例えば３か月等）としてもよい。あるいは、図１９に示すように、２人のプレイヤの仲間関係の復活回数を記憶装置（データベースサーバ２等）に記憶しておき、復活回数に応じて所定期間を変動させてもよい。例えば、前記の所定回数を、２人のプレイヤの復活回数が２回目なら２か月、３回目なら３か月、４回目なら４か月・・・に設定するというように、復活回数が多くなるほど所定期間を長く設定するようにする。これにより、ポイント狙いによる仲間関係の復活の繰り返しが多くなればなるほど、復活が禁止される期間も長くなるので、不適正なポイント狙いのプレイヤの行動を、効果的に抑制することができる。
本実施の形態のゲームサーバ１における再復活制限処理の例を、図２７および図２８を参照して以下に説明する。なお、図２７および図２８のフローチャートは、仲間（現在または過去の仲間）同士の２人のプレイヤを対象としたゲームサーバ１の処理の流れを示すものであり、ゲームサーバ１が管理している全ての仲間同士のペアに対して同様の処理が行われることになる。
図２７に示すように、２人のプレイヤ間で仲間復活申請およびその承認が行われたことにより、仲間復活処理が実行されたとき（Ｓ１１１でＹＥＳ）、復活時間記憶手段１０４が復活時間をデータベースサーバ２に記憶する（Ｓ１１２）。その後、仲間関係が復活した２人のプレイヤの何れか一方が解除操作を行って当該２人の仲間関係が解除された場合（Ｓ１１３でＹＥＳ）、所定期間が経過するまで仲間関係の再復活を制限する処理（Ｓ１１４〜Ｓ１１７のループ処理）に移行する。すなわち、何れか一方のプレイヤにより仲間復活申請の操作が行われても（Ｓ１１４でＹＥＳ）、復活時間から所定期間が経過していなければ（Ｓ１１５でＮＯ）、再復活制限手段１０５は仲間復活申請を許可しない（Ｓ１１６）。これにより、仲間復活申請手段１０２による仲間復活申請処理が実行されることはない。この場合、ゲームサーバ１は、仲間復活申請の操作を行ったプレイヤの端末装置３に、前回の復活から所定期間が経過するまでは再復活は禁止されている旨を報知するための情報を送信する（Ｓ１１７）。
一方、何れか一方のプレイヤにより仲間復活申請の操作が行われたときに（Ｓ１１４でＹＥＳ）、既に復活時間から所定期間が経過しているのであれば（Ｓ１１５でＹＥＳ）、仲間復活申請手段１０２が仲間復活申請処理を実行する（Ｓ１１８）。その後、他方のプレイヤが仲間復活申請を承認したとき（Ｓ１１９）、仲間管理手段５４が仲間復活処理を実行する（Ｓ１２０）。その後は、Ｓ１１２の処理に戻って復活時間記憶手段１０４が復活時間を記憶（更新）する。
上記のように、一度仲間関係を復帰させた２人のプレイヤは、その復帰後、所定期間が経過するまで、仲間復活申請が受け付けられないので仲間関係の再度の復活が制限される。
次に、ゲームサーバ１における再復活制限処理の他の例を、図２８を参照して説明する。２人のプレイヤの仲間復活処理が実行されたとき（Ｓ１１１でＹＥＳ）、復活時間記憶手段１０４が復活時間をデータベースサーバ２に記憶する（Ｓ１１２）。その後、２人の仲間関係が解除され（Ｓ１１３でＹＥＳ）、さらにその後、何れか一方のプレイヤにより仲間復活申請の操作が行われた場合（Ｓ１２１でＹＥＳ）、復活時間から所定期間が経過しているか否かにかかわらずに、仲間復活申請手段１０２が仲間復活申請処理を実行する（Ｓ１２２）。この仲間復活申請処理において、仲間復活申請を受けたプレイヤの端末装置３に、前回の復活から所定期間が経過するまで承認できない旨を報知するための情報を送信する。また、仲間復活申請の操作を行ったプレイヤの端末装置３にも、前回の復活から所定期間が経過するまで相手が承認できない旨を報知するための情報を送信することが望ましい。
その後、他方のプレイヤから承認の操作が行われても（Ｓ１２３でＹＥＳ）、復活時間から所定期間が経過していなければ（Ｓ１２４でＮＯ）、再復活制限手段１０５は承認を許可しない（Ｓ１２５）。これにより仲間管理手段５４による仲間復活処理が実行されることはない。この場合、ゲームサーバ１は、承認の操作を行ったプレイヤの端末装置３に、前回の復活から所定期間が経過するまでは再復活は禁止されている旨を報知するための情報を送信する（Ｓ１２６）。
一方、承認の操作が行われたときに（Ｓ１２３でＹＥＳ）、既に復活時間から所定期間が経過しているのであれば（Ｓ１２４でＹＥＳ）、仲間管理手段５４が仲間復活処理を実行する（Ｓ１２７）。その後は、Ｓ１１２の処理に戻って復活時間記憶手段１０４が復活時間を記憶（更新）する。
上記のように、一度仲間関係を復帰させた２人のプレイヤは、その復帰後、所定期間が経過するまで、承認が受け付けられないので仲間関係の再度の復活が制限される。
本実施の形態の構成により、２人のプレイヤが仲間関係の解除と復活とを繰り返すことによる不適正なポイント狙いを画策しても、一度仲間関係を復活させた後は、所定期間（例えば３か月）が経過するまで再度の復活ができなくなる。よって、仲間同士でポイントの獲得だけを狙って仲間関係の解除と復活とを短期間で繰り返すという不適正なプレイヤの行動を、効果的に抑制することができる。
次に、仲間同士でポイントの獲得だけを狙って仲間関係の解除と復活とを短期間で繰り返す事態を回避するための他の構成について、以下に説明する。
仲間履歴送信手段１０１は、復活時間記憶手段１０４が記憶した２人のプレイヤの復活時間から所定期間（例えば３か月）が経過するまでは、当該２人のプレイヤの仲間関係が再度解除された場合であっても、当該２人のプレイヤのうちの一方のプレイヤが操作する端末装置３からの要求に応じて過去の仲間プレイヤを表示させるための情報を当該端末装置３へ送信するときに、送信する情報の中に他方のプレイヤの情報を含めない機能を有する。この仲間履歴送信手段１０１が実行する仲間履歴送信処理の一例を、図２９のフローチャートに示す。
プレイヤが端末装置３を操作して、例えばメイン画面中の「過去の仲間リスト」ボタンを選択すれば、端末装置３から過去の仲間リスト要求がゲームサーバ１へ送信される。この要求をゲームサーバ１が受信すれば（Ｓ１３１でＹＥＳ）、仲間履歴送信手段１０１は、仲間情報記憶手段５４ａが記憶しているプレイヤの過去の仲間情報のうち、復活時間記憶手段１０４が記憶している当該プレイヤの復活時間から所定期間（例えば３か月）が経過した過去の仲間情報のみを抽出して読み出す（Ｓ１３２）。そして、仲間履歴送信手段１０１は、復活時間から所定期間を経過していない過去の仲間プレイヤを含まない過去の仲間リスト画面データを、プレイヤの端末装置３に送信する（Ｓ１３３）。
また、図３０のフローチャートには、仲間（現在または過去の仲間）同士の２人のプレイヤを対象としたゲームサーバ１における再復活制限処理の流れを示している。
２人のプレイヤの仲間復活処理が実行されたとき（Ｓ１１１でＹＥＳ）、復活時間記憶手段１０４が復活時間をデータベースサーバ２に記憶する（Ｓ１１２）。その後、２人の仲間関係が解除され（Ｓ１１３でＹＥＳ）、さらにその後、２人のプレイヤの何れか一方のプレイヤの端末装置３において過去の仲間リストを要求する操作（「過去の仲間リスト」ボタンの選択等）が行われた場合（Ｓ１４１でＹＥＳ）は、当該２人のプレイヤの復活時間から所定期間が経過しているか否かで以降の処理が分岐される（Ｓ１４２）。ここで、２人のプレイヤの復活時間から所定期間が経過していなければ（Ｓ１４２でＮＯ）、仲間履歴送信手段１０１は、相手のプレイヤを含まない過去の仲間リスト画面データを、プレイヤの端末装置３に送信する（Ｓ１４３）。一方、２人のプレイヤの復活時間から所定期間が経過している場合（Ｓ１４２でＹＥＳ）、仲間履歴送信手段１０１は、相手のプレイヤを含む過去の仲間リスト画面データを、プレイヤの端末装置３に送信する（Ｓ１４４）。
本実施の形態の構成により、２人のプレイヤが仲間関係の解消と復活とを繰り返すことによる不適正なポイント狙いを画策しても、一度仲間関係を復活させた後は、所定期間（例えば３か月）が経過するまで、お互い相手のプレイヤが過去の仲間プレイヤとして端末装置３に表示されないので、仲間復活申請ができなくなる。よって、仲間同士でポイントの獲得だけを狙って仲間関係の解消と復活とを短期間で繰り返すという不適正なプレイヤの行動を、効果的に抑制することができる。
次に、仲間同士でポイントの獲得だけを狙って仲間関係の解除と復活とを短期間で繰り返す事態を回避するためのさらに他の構成について、以下に説明する。
図２５に示すように、ゲームサーバ１は、２人のプレイヤの仲間関係の復活回数を記憶装置（データベースサーバ２）に記憶する復活回数記憶手段１０６を備えている。例えば、図１９に示すように、復活回数記憶手段１０６は、仲間関係が復活した２人のプレイヤを関係付けた仲間情報ＩＤと対応付けて、復活回数をデータベースサーバ２に記憶する。
そして、再復活制限手段１０５は、２人のプレイヤの復活回数が所定回数（例えば５回）に達した場合、当該２人の所定回数を超えての再度の復活を許可しない。
本ゲームサーバ１における再復活制限処理の例を、図３１を参照して説明する。２人のプレイヤの仲間復活処理が実行されたとき（Ｓ１５１でＹＥＳ）、復活回数記憶手段１０６が復活回数Ｎをデータベースサーバ２に記憶（更新）する（Ｓ１５２）。なお、もしも２人のプレイヤの復活回数が所定回数に達した場合、ゲームサーバ１は、当該２人のプレイヤの端末装置３に、これ以上の復活はできない旨を報知するための情報を送信することが望ましい。
その後、２人の仲間関係が解除され（Ｓ１５３でＹＥＳ）、さらにその後、何れか一方のプレイヤにより仲間復活申請の操作が行われた場合は（Ｓ１５４でＹＥＳ）、当該２人の復活回数Ｎが所定回数未満か否かで以降の処理が分岐される（Ｓ１５５）。ここで、２人の復活回数Ｎが所定回数未満の場合（Ｓ１５５でＹＥＳ）、仲間復活申請手段１０２が仲間復活申請処理を実行する（Ｓ１５６）。その後、他方のプレイヤが仲間復活申請を承認したとき（Ｓ１５７）、仲間管理手段５４が仲間復活処理を実行する（Ｓ１５８）。その後は、Ｓ１５２の処理に戻って復活回数記憶手段１０６が復活回数Ｎを記憶（更新）する。
一方、２人の復活回数Ｎが所定回数に達している場合（Ｓ１５５でＮＯ）、再復活制限手段１０５は仲間復活申請を許可しない（Ｓ１５９）。これにより、仲間復活申請手段１０２による仲間復活申請処理が実行されることはない。この場合、ゲームサーバ１は、仲間復活申請の操作を行ったプレイヤの端末装置３に、所定回数の復活を繰り返した相手とはもはや復活できない旨を報知するための情報を送信する（Ｓ１６０）。
これにより、２人のプレイヤが仲間関係の解消と復活とを繰り返すことによる不適正なポイント狙いを画策しても、所定回数を超える復活はできないので、不適正なポイント狙いを抑制することができる。
〔ゲーム管理装置の他の構成例〕
次に、上述の構成（仲間復活申請が可能な構成）が好適なゲーム管理装置について説明する。このゲーム管理装置は、仲間関係が成立している２人のプレイヤに仲間期間を設定し、その仲間期間が終了したら仲間関係を自動解除する構成を有する。このように、プレイヤによる意図的な解除ではなく、２人のプレイヤに設定された仲間期間の終了により仲間関係が自動解除される場合、仲間関係の解除が多くなる分、仲間関係を復活させたいと考える機会もまた多くなるため、仲間復活申請を簡単な操作で容易に行うことができる上述の構成が好適である。
以下に、本実施の形態のゲーム管理装置について、図３２の機能ブロック図を参照しながら説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。
図３２に示すように、ゲームサーバ１（ゲーム管理装置）は、図４に示した各手段に加えて、仲間期間設定手段５６、仲間関係解除手段５７および仲間期間報知手段５８をさらに備えている。これらの手段５６〜５８は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。
仲間期間設定手段５６は、仲間関係が成立している２人のプレイヤに対して、プレイヤ間の仲間関係が継続される仲間期間を設定する機能を有する。仲間期間が終了すれば、原則、２人の仲間関係は自動的に解除されることになる。
ここで、仲間期間設定手段５６が設定する仲間期間の長さとしては、例えば１週間、１０日、２週間、１ヶ月など、任意の期間長さに設定可能である。また、仲間期間の長さは固定であってもよいし、例えば設定時にランダムに期間長さを変えてもよい。さらには、プレイヤ間のレベル関係に応じた適切な期間長さを設定するようにしてもよい。
本実施の形態では、プレイヤ間のレベル関係に応じた期間長さを設定する構成の仲間期間設定手段５６について、以下に説明する。
仲間期間設定手段５６は、仲間申請をしたプレイヤ（第１のプレイヤ）および当該仲間申請を承認したプレイヤ（第２のプレイヤ）の２人のプレイヤ間での仲間関係の成立時に、第１のプレイヤのゲームレベルと第２のプレイヤのゲームレベルとの関係を含む所定条件に基づいて、仲間期間を設定する機能を有する。
ここで、仲間期間を決定するために用いられる「ゲームレベル」とは、プレイヤのゲームの進行度合い、熟練度、力量等を直接的または間接的に示す指標情報である。このゲームレベルとしては、（ａ）プレイヤ自身のレベル、（ｂ）プレイヤのゲーム内の所有物のレベル（所有物の例：キャラクタ、キャラクタの集合体であるグループ・チーム・ユニット、アイテム等）、（ｃ）プレイヤのゲーム内の所有物の数・所有物の能力値等から算出される値、（ｄ）プレイヤが達成したステージのレベルや現在所属しているリーグのレベル、等を挙げることができる。
前記（ａ）の具体例としては、プレイヤがゲームを進行させて経験値を蓄積することによりレベルアップするゲームにおけるプレイヤのレベルがある。また、前記（ｂ）の具体例としては、プレイヤが所有するキャラクタを練習モード、試合モード、育成モード、合成モード等で使用することによりキャラクタの強化・レベルアップを図るゲームにおけるキャラクタのレベルがある。ここで、キャラクタのレベルとは、キャラクタの成長度合い、能力の高さ、強さ等を表す値であればよく、キャラクタの能力値であってもよい。
また、前記（ｃ）の具体例としては、プレイヤがゲームを進行させることによりキャラクタやアイテムを取得するゲームにおいて、プレイヤが所有するキャラクタやアイテムの数の多さを評価する値がある。例えば、プレイヤが所有する所定の能力値以上のキャラクタ（選手カード）の数をプレイヤのゲームレベルとすることができる。
また、前記（ｄ）の具体例としては、ゲーム内にレベル（難易度）の異なる複数のステージが設けられており、１つのステージをクリアしたら１つ難易度の高い別のステージに進むようなゲームにおけるプレイヤが達成したステージのレベルがある。また、前記（ｄ）の他の具体例としては、プレイヤがリーグ戦で上位の成績を獲得することによって、よりレベルの高いリーグに所属できるようなゲームにおける現在所属しているリーグのレベルがある。
本実施の形態では、仲間期間を決定するために用いられるゲームレベルとして、前記（ａ）プレイヤ自身のレベルを適用した例について以下に説明する。
仲間期間設定手段５６は、仲間申請をした第１のプレイヤとそれを承認した第２のプレイヤとのレベル関係を含む所定条件に基づいて仲間期間を決定するのであるが、その例を次に説明する。仲間期間設定手段５６は、第１のプレイヤよりもゲームレベルが高い第２のプレイヤが仲間申請を承認した場合に設定する仲間期間を、第１のプレイヤとゲームレベルが同じ又は第１のプレイヤよりもゲームレベルが低い第２のプレイヤが仲間申請を承認した場合に設定する仲間期間よりも短くする。その具体例としては、仲間申請をした第１のプレイヤのレベルをＬ１、それを承認した第２のプレイヤのレベルをＬ２とした場合、仲間期間設定手段５６は、Ｌ１＜Ｌ２のときには５日、Ｌ１＝Ｌ２のときには７日、Ｌ１＞Ｌ２のときには１０日の仲間期間とする。なお、仲間期間の日数はこれらに限定されるものではなく、例えばＬ１＜Ｌ２のときには１週間、Ｌ１＝Ｌ２のときには２週間、Ｌ１＞Ｌ２のときには３週間とするなど、任意の期間を設定できる。
Ｌ１＜Ｌ２の場合とは、第１のプレイヤよりもゲームレベルが高い第２のプレイヤが仲間申請を承認した場合である。この場合は、承認した第２のプレイヤにとって、自分よりも下位レベルのプレイヤ（即ち、対戦協力等の貢献度の低いプレイヤ）と仲間になるのであるから、自分が望むような交流等ができない仲間であった場合には短期間で仲間関係を解消したいと希望することが多い。そこで、Ｌ１＝Ｌ２の場合（同レベル間で仲間成立）またはＬ１＞Ｌ２の場合よりも仲間期間を短くしている。
一方、Ｌ１＞Ｌ２の場合とは、第１のプレイヤよりもゲームレベルが低い第２のプレイヤが仲間申請を承認した場合である。この場合は、承認した第２のプレイヤにとって、自分よりも上位レベルのプレイヤ（即ち、対戦協力等の貢献度の高いプレイヤ）と仲間になるのであるから、Ｌ１＝Ｌ２またはＬ１＜Ｌ２の場合よりも仲間関係を長く継続したいと希望することが多い。そこで、Ｌ１＝Ｌ２またはＬ１＜Ｌ２の場合よりも仲間期間を長くしている。
上記のように、仲間申請を承認した側が申請した側よりも上位レベルであるか否かによって仲間期間を変えることにより、承認した側のプレイヤの希望に沿った適切な仲間期間の設定が可能となる。このように、仲間申請をした側のプレイヤではなく、仲間申請を承認した側のプレイヤからみた適切な仲間期間の設定を行う理由は、次の通りである。すなわち、仲間申請をした側のプレイヤにとっては、相手のプレイヤのレベルにかかわらずその相手と仲間になりたいと考えて仲間申請しているはずである。一方、仲間申請を受けたプレイヤにとっては、それを拒否することもできるが、下位プレイヤからの申請だからといって無碍に断れずにその申請を承認してしまい、後で後悔することも従来は多かった。そこで、仲間申請を承認した側のプレイヤからみた適切な仲間期間の設定を行うのである。
次に、仲間期間設定手段５６による仲間期間決定処理の他の例を説明する。仲間期間設定手段５６は、仲間関係が成立したプレイヤ間のレベル差に応じて、仲間期間を設定するようになっている。以下、仲間申請をした第１のプレイヤのレベルをＬ１、それを承認した第２のプレイヤのレベルをＬ２、Ｌ１とＬ２との差をレベル差Ｄとして説明を続ける。また、図３３には、レベル差Ｄと仲間期間との関係を表すテーブルを例示している。このテーブルの情報は、ゲームサーバ１の記憶手段（ＲＡＭ１３または補助記憶装置１４等）に記憶されており、仲間期間設定手段５６による処理中に参照される。
まず、仲間申請した第１のプレイヤよりもレベルが高い第２のプレイヤが仲間申請を承認した場合を考える（Ｌ１＜Ｌ２の場合）。この場合、図３３に例示するテーブルに示すように、仲間期間設定手段５６は、レベル差Ｄが大きいほど、仲間期間を段階的に短く設定する。図３３のテーブルの例では、レベル差Ｄが１〜９のとき７日、１０〜２９のとき６日、３０〜４９のとき５日、５０〜６９のとき４日、７０〜９９のとき３日、１００以上のとき２日に設定される。なお、仲間期間の日数はこれらに限定されるものではなく、レベル差Ｄが大きいほど仲間期間が短くなるという条件を満たせば、任意の期間を設定できる。
このように、仲間申請した第１のプレイヤよりもレベルが高い第２のプレイヤが仲間申請を承認した場合は、承認した第２のプレイヤにとって、自分よりも下位レベルの第１のプレイヤとのレベル差Ｄが大きいほど、第１のプレイヤから受ける対戦協力等による貢献の程度は小さくなる。そこで、この場合には、レベル差Ｄが大きいほど仲間期間を短く設定することにより、より適切な仲間期間の設定を実現しているのである。
次に、仲間申請した第１のプレイヤよりもレベルが低い第２のプレイヤが仲間申請を承認した場合を考える（Ｌ１＞Ｌ２の場合）。この場合、図３３に例示するテーブルに示すように、仲間期間設定手段５６は、レベル差Ｄが大きいほど、仲間期間を段階的に長く設定する。図３３のテーブルの例では、レベル差Ｄが１〜９のとき７日、１０〜２９のとき８日、３０〜４９のとき９日、５０〜６９のとき１０日、７０〜９９のとき１１日、１００以上のとき１２日に設定される。なお、仲間期間の日数はこれらに限定されるものではなく、レベル差Ｄが大きいほど仲間期間が長くなるという条件を満たせば、任意の期間を設定できる。
このように、仲間申請した第１のプレイヤよりもレベルが低い第２のプレイヤが仲間申請を承認した場合は、承認した第２のプレイヤにとって、自分よりも上位レベルの第１のプレイヤとのレベル差Ｄが大きいほど、第１のプレイヤから受ける対戦協力等による貢献の程度は大きくなる。そこで、この場合には、レベル差Ｄが大きいほど仲間期間を長く設定することにより、より適切な仲間期間の設定を実現しているのである。
また、仲間申請した第１のプレイヤとそれを承認した第２のプレイヤのレベルが同じ場合（Ｌ１＝Ｌ２の場合）、図３３に例示するように、仲間期間設定手段５６は、仲間期間を７日に設定する。
仲間期間設定手段５６は、仲間関係が成立した２人のプレイヤに対して設定した仲間期間をデータベースサーバ２（記憶装置）に記憶する仲間期間記憶手段５６ａを備えている。図３４に、仲間期間記憶手段５６ａが記憶する仲間期間の例を示している。仲間期間記憶手段５６ａは、仲間情報ＩＤと対応づけて、仲間期間（期間の長さ）および仲間期間終了予定時間等を記憶する。ここで、仲間期間終了予定時間とは、仲間期間の最終時刻にあたる現実世界の時間情報であり、年、月、日、時、分、秒等の時間が記憶される。ここで時間の単位は任意に設定できる。本実施の形態では、仲間期間記憶手段５６ａが、仲間期間終了予定時間として、仲間期間の最終時刻にあたる現実世界の日付（年月日）を記憶する例を示す。また、仲間期間記憶手段５６ａが、仲間情報ＩＤと対応づけて、仲間期間が設定された日時や仲間関係が成立した日時等の時間情報を併せて記憶してもよい。
次に、仲間関係解除手段５７について説明する。仲間関係解除手段５７は、仲間関係が成立している２人のプレイヤに対して設定された仲間期間の終了により、当該２人のプレイヤの仲間関係を自動的に解除する機能を有する。ここで、自動的に解除するとは、プレイヤによる自主的な解除操作がなくとも、ゲームサーバ１側で仲間関係の解除処理を実行することを意味する。仲間関係解除手段５７は、データベースサーバ２に登録されている図８に示す仲間情報のうち、仲間関係が解除された仲間情報に該当する情報に解除フラグを付加したり当該情報を削除したりすることにより、仲間関係の解除処理を実行する。
次に、仲間期間報知手段５８について説明する。プレイヤは、端末装置３に表示される仲間リスト等の画面で、自分の仲間プレイヤとの間に設定されている仲間期間がいつまでなのかを確認できるようになっている。これを実現するために、仲間期間報知手段５８は、仲間期間記憶手段５６ａに記憶されている仲間期間の情報を読み出し、プレイヤと仲間プレイヤとの間に設定されている仲間期間を表示させるための情報を、当該プレイヤの端末装置３へ送信し、プレイヤに仲間期間を報知する機能を有する。すなわち、仲間期間報知手段５８は、仲間期間を含む画面データをプレイヤの端末装置３へ送信して、端末装置３の画面に仲間期間を表示させる制御を行う。
仲間期間を含む画面の例としては、図３５に示すような仲間リスト画面が挙げられる。仲間リスト画面には、リストアップされた各仲間との間に設定されている仲間期間を表示するための仲間期間表示領域８０が設けられている。
図３５には、仲間期間表示領域８０に、仲間期間の終了予定日（１／１７まで等）が表示される画面例を示している。なお、仲間期間表示領域８０に表示される仲間期間の情報は、仲間期間の終了予定日に限定されるものではなく、仲間期間の終了予定時間（年、月、日、時、分、秒等の任意の単位の時間情報）としてもよい。あるいは、例えば仲間期間の残日数（あと１０日間等）や残時間（あと２０時間１０分１５秒等）が仲間期間表示領域８０に表示されるようにしてもよい。
次に、図３６ないし図３８を参照して、ゲームサーバ１における仲間期間設定および仲間解除処理について説明する。図３６ないし図３８のフローチャートは、仲間関係が成立したある２人のプレイヤを対象としたゲームサーバ１の処理の流れを示すものであり、ゲームサーバ１が管理している全ての仲間同士のペアに対して同様の処理が行われることになる。
図３６に示すように、第１のプレイヤから仲間申請を受けた第２のプレイヤがそれを承認することによって、２人のプレイヤ間で仲間関係が成立した場合（Ｓ２５１でＹＥＳ）、仲間期間設定手段５６が、第１のプレイヤのレベルと第２のプレイヤのレベルとの関係を含む所定条件に基づいて仲間期間を決定する（Ｓ２５２）。
このＳ２５２の仲間期間決定処理の一例を、図３７に示す。図３７中において、仲間申請をした第１のプレイヤのレベルをＬ１、それを承認した第２のプレイヤのレベルをＬ２として表している。仲間期間設定手段５６は、Ｌ１＜Ｌ２のとき（Ｓ２６１でＹＥＳ）、仲間期間を５日とする（Ｓ２６２）。また、仲間期間設定手段５６は、Ｌ１＞Ｌ２のとき（Ｓ２６１でＮＯおよびＳ２６３でＹＥＳ）、仲間期間を１０日とする（Ｓ２６４）。また、仲間期間設定手段５６は、Ｌ１＝Ｌ２のとき（Ｓ６１でＮＯおよびＳ６３でＮＯ）、仲間期間を７日とする（Ｓ２６５）。
図３６のＳ５２の仲間期間決定処理の他の例を、図３８に示す。仲間期間設定手段５６は、仲間申請をした第１のプレイヤのレベルＬ１と、それを承認した第２のプレイヤのレベルＬ２との差であるレベル差Ｄを算出する（Ｓ２７１）。そして、仲間期間設定手段５６は、Ｌ１＜Ｌ２のとき（Ｓ２７２でＹＥＳ）、レベル差Ｄが大きいほど仲間期間を短くする（Ｓ２７３）。例えば、図３３に例示するテーブルを参照し、レベル差Ｄに応じた仲間期間（Ｌ１＜Ｌ２の場合）を取得する。また、仲間期間設定手段５６は、Ｌ１＞Ｌ２のとき（Ｓ２７２でＮＯおよびＳ２７４でＹＥＳ）、レベル差Ｄが大きいほど仲間期間を長くする（Ｓ２７５）。例えば、図３３に例示するテーブルを参照し、レベル差Ｄに応じた仲間期間（Ｌ１＞Ｌ２の場合）を取得する。また、仲間期間設定手段５６は、Ｌ１＝Ｌ２のとき（Ｓ２７２でＮＯおよびＳ２７４でＮＯ）、仲間期間を７日とする（Ｓ２７６）。
図３６に戻って説明を続けると、仲間期間設定手段５６は、上記のように仲間関係成立時に決定した仲間期間を、第１のプレイヤおよび第２のプレイヤに対して設定する（Ｓ２５３）。例えば、仲間期間設定手段５６は、図３４に示すように、仲間関係が成立している２人のプレイヤを関係付けた仲間情報と対応付けて、仲間期間を記憶する。
その後、仲間関係が成立している２人のプレイヤに設定された仲間期間が終了した場合（Ｓ２５４でＹＥＳ）、仲間関係解除手段５７は、当該２人のプレイヤの仲間関係を自動的に解除する（Ｓ２５５）。例えば、仲間関係解除手段５７は、データベースサーバ２に登録されている２人の仲間情報に解除フラグを付加することにより、仲間関係の解除処理を実行する。
その後、ゲームサーバ１は、仲間関係が解除された２人のプレイヤの端末装置３に対して、仲間関係が解除された旨を報知するための情報（解除の旨を含む画面データ等）を送信し、当該２人のプレイヤに仲間関係が解除されたことを報知する（Ｓ２５６）。報知の例としては、ゲーム画面の中に仲間関係が解除された旨を表示することの他に、音声による報知や画面表示と音声とを併用した報知も考えられる。音声による報知は、ゲームサーバ１からプレイヤの端末装置３へ送信する画面データ（ＨＴＭＬデータ等）に音声データを含ませることにより実現できる。なお、ゲームサーバ１が、仲間関係が解除されたことを報知するためには、プレイヤの端末装置３がゲームサーバ１にアクセスしている必要がある。よって、ゲームサーバ１は、Ｓ２５５の仲間関係の解除処理を実行した後、仲間関係が解除された各プレイヤの端末装置３がゲームサーバ１に最初にアクセスしたときに、Ｓ２５６の報知処理を実行することになる。
次に、仲間期間設定手段５６が、仲間関係が成立した２人のプレイヤ間のレベル差に応じて仲間期間を設定する構成において、仲間期間中にレベル差が変動した場合に、変動後のレベル差に応じた仲間期間に再設定する構成について説明する。ここでは、図３３に示すテーブルに基づいて、仲間期間設定手段５６がプレイヤ間のレベル差に応じた仲間期間を設定する場合を例に挙げて説明する。
図３９に示すように、ゲームサーバ１は、レベル差記憶手段６０を備えている。なお、図３９に示すゲームサーバ１は、図４に記載の仲間履歴送信手段１０１および仲間復活申請手段１０２を具備しているが、図３９中ではこれらの手段１０１・１０２の記載を省略している。さらに、図３９に示すゲームサーバ１は、図２５に記載の復活時間記憶手段１０４、再復活制限手段１０５および復活回数記憶手段１０６を具備する構成であってもよい。
レベル差記憶手段６０は、仲間期間設定時（再設定時を含む）における、仲間申請した第１のプレイヤのレベルＬ１とそれを承認した第２のプレイヤのレベルＬ２との差であるレベル差を、データベースサーバ２（記憶装置）に記憶する機能を有する。例えば、図４０Ａに示すように、レベル差記憶手段６０は、両プレイヤの仲間情報を一意に示す仲間情報ＩＤと対応付けて、仲間期間設定時のプレイヤ間のレベル差を記憶するようになっている。この例では、レベル差をＬ１−Ｌ２として算出し、Ｌ１＞Ｌ２のときのレベル差はプラスの値、Ｌ１＜Ｌ２のときのレベル差はマイナスの値として管理できるようにしている。このレベル差記憶手段６０は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。
そして、仲間期間設定手段５６は、仲間期間中のプレイヤ間のレベル差が、レベル差記憶手段６０に記憶されている仲間期間設定時におけるレベル差から変動した場合に、変動後のレベル差に応じて仲間期間を再設定する機能を有する。この仲間期間の再設定処理について、図４１のフローチャートを参照しながら以下に説明する。なお、既出のフローチャートにおいて示したステップと同様のステップについては同一のステップ番号を付し、詳細な説明を省略する（以降のフローチャートにおいても同様である）。
仲間期間設定手段５６が仲間関係成立時に２人のプレイヤに対して仲間期間を設定した場合（Ｓ３０１でＹＥＳ）、レベル差記憶手段６０が仲間期間設定時におけるプレイヤ間のレベル差を記憶する（Ｓ３０２）。
その後、仲間期間設定手段５６は、仲間期間中に（Ｓ３０３でＮＯ）、少なくとも一方のプレイヤのレベルが変化することによりプレイヤ間のレベル差の変動を検出した場合（Ｓ３０４でＹＥＳ）、変動後のレベル差に応じて仲間期間の再設定の必要性を判断する（Ｓ３０５）。すなわち、図３３に示すテーブルに基づいて取得した変動後のレベル差に応じた仲間期間が、仲間期間設定時における仲間期間から変化しているか否かを判断する。具体例を挙げると、仲間成立時において、仲間申請したプレイヤのレベルＬ１が３０であり、それを承認したプレイヤのレベルＬ２が５７であったとする。よって、図４０Ａの仲間情報ＩＤ＝“２０”に示すように、プレイヤ間のレベル差−２７（＝３０−５７）に応じた仲間期間として６日が設定されたとする。その後、仲間期間中に、承認した側のプレイヤのレベルＬ２が１つ向上して５８になり、プレイヤ間のレベル差が−２８になっても、図３３のテーブルに基づけば、Ｌ１＜Ｌ２の場合、レベル差が１０〜２９の範囲では仲間期間は６日のままであることから、仲間期間の再設定の必要性はないことになる。例えば、仲間期間中にレベル差が−３０になった場合、図３３のテーブルに基づけば、変動後のレベル差に応じた仲間期間は５日になり、仲間期間を再設定する必要性が生じる。
仲間期間の再設定が必要である場合（Ｓ３０５でＹＥＳ）、仲間期間設定手段５６は、変動後のレベル差に応じた仲間期間を再設定する（Ｓ３０６）。例えば、図４０Ａに示す仲間情報ＩＤ＝“２０”の仲間期間および仲間期間終了予定時間を、図４０Ｂに示す情報に更新する。すなわち、仲間期間設定手段５６は、データベースサーバ２に記憶している仲間期間を、６日から５日に短縮し、それに伴って仲間期間終了予定時間も１日早くする（１１／１／１０から１１／１／９へ更新する）。
上記では、再設定された仲間期間が元の期間よりも短くなる例を示したが、当然、再設定された仲間期間が元の期間よりも長くなる場合もある。仲間期間の再設定が実行されたときは、Ｓ１０２に戻って、レベル差記憶手段６０が再設定時におけるプレイヤ間のレベル差を記憶（更新）する。
なお、仲間期間が終了した場合は（Ｓ３０３でＹＥＳ）、仲間関係解除手段５７により仲間関係が自動的に解除され（Ｓ２５５）、仲間関係が解除されたことが２人のプレイヤの端末装置３に報知される（Ｓ２５６）。
このように、プレイヤ間のレベル差に応じて適切な仲間期間を設定した後、その仲間期間中にプレイヤ間のレベル差が変動した場合、変動後のレベル差に応じた仲間期間に再設定することにより、仲間期間設定後のプレイヤ間のレベル差変動に追従した適切な仲間期間の調整を実現できる。
なお、上記では、仲間期間設定手段５６がプレイヤ間での仲間関係の成立時に、仲間期間を設定する構成について説明したが、これに限定されるものではなく、仲間期間設定手段５６が仲間期間を設定するタイミングについては、任意に定めることができる。
例えば、仲間期間設定手段５６による仲間期間の設定タイミングは、プレイヤ間で仲間関係が成立してから一定期間経過後とすることができる。ここで、一定期間としては、例えば、３日、１週間、１０日、２週間、１か月等、任意の期間を設定することができる。このように、仲間関係の成立直後の一定期間を猶予期間として、仲間期間が設定されることにより仲間関係が自動解除され得る状態には移行しないようにしてもよい。
以上のように、本実施の形態では、２人のプレイヤ間での仲間関係の成立時に仲間期間を設定し、仲間期間の終了により、原則的に、当該２人のプレイヤの仲間関係を自動的に解除するようになっている。これにより、例えば、下位レベルのプレイヤからの仲間申請を承認して仲間になっても、仲間になった時点で仲間期間が設定されるので、プレイヤは、心理的にも行い難い仲間解除の操作をすることなく、仲間期間の終了により仲間関係の解除が可能となる。そして、プレイヤは、仲間関係の成立から仲間期間の終了までの間に、相手との交流の程度等から判断して仲間関係を継続すべきかどうかを判断することができる。そして、仲間関係を継続したいと思うような相手であれば、例えば、仲間期間終了後に改めて仲間申請を行う等の所定の操作をして仲間関係を継続すればよい。
すなわち、仲間関係成立時に設定される仲間期間をお試し期間として捉えて、例えば自分より下位レベルのプレイヤから仲間申請を受けたような場合でも、これを積極的に承諾して試しに仲間になり、仲間期間終了までに自分が望むような交流等ができる相手かどうかを検討することも可能となる。
また、各プレイヤが他のプレイヤと仲間関係を構築することができる仲間数に上限が設定されているゲームにおいて、プレイヤの仲間数が上限に達していた場合でも、仲間期間終了に伴う仲間関係の自動解除により、上限までに余裕ができる。すなわち、仲間数が一旦上限まで達したプレイヤであっても、従来のように実質的に仲間が固定された状態に陥ることはなく、他のプレイヤと新たな仲間関係を構築するための機会が与えられる。
そして、プレイヤは、仲間期間中に交流が持てなかった下位レベルのプレイヤとは、自動解除された仲間関係を終え、再度、仲間申請や承認をしたりすることはないと考えられる。その一方、プレイヤが望むような相手（上位レベルのプレイヤや楽しく交流が持てるようなプレイヤ）とは、仲間関係を継続するために、上述の仲間復活申請や承認等の操作をすることが考えられる。よって、本実施の形態の構成により、仲間関係成立による仲間期間設定と、仲間期間終了による仲間関係の自動解除と、必要に応じた仲間関係復活の申請とを繰り返しながら、プレイヤの好むような仲間グループの構成に収束されていく環境が整えられる。したがって、プレイヤが、あまり交流のない下位レベルの仲間プレイヤを何人も抱え、自分好みの仲間のグループ構成になっていない状態で実質的に仲間が固定されてしまうことへの不満を解消できる。
特に、仲間数に上限が設定されているゲームの場合、従来では、比較的レベルの高いプレイヤが、あまり交流のない下位レベルの仲間を何人も抱えた状態で仲間数が上限まで達し、仲間が固定されてしまうことが多かった。これに対し、本ゲームサーバ１を適用した場合、仲間数に上限が設定されているゲームであっても、他のプレイヤと新たな仲間関係を構築し易すい環境がプレイヤに提供されるので、継続的に新たな仲間との交流を楽しめるようになる。よって、長期間にわたりゲームを継続しても、ゲームに対するマンネリ感が発生しにくい。
ところで、仲間関係が解除されても、仲間関係の復活により、再度、仲間関係が成立した場合、改めて仲間期間設定手段５６により仲間期間が設定されることになる。すなわち、仲間期間設定手段５６は、仲間復活申請をしたプレイヤ（第１のプレイヤ）および当該仲間復活申請を承認したプレイヤ（第２のプレイヤ）の２人のプレイヤ間での仲間関係の成立時に、第１のプレイヤのゲームレベルと第２のプレイヤのゲームレベルとの関係を含む所定条件に基づいて仲間期間を決定し、当該２人のプレイヤに対して仲間期間を設定するのである。
２人のプレイヤ間で上記のようにして仲間関係が復活した場合、初めて仲間関係が成立した場合よりも、当該２人のプレイヤは仲間関係の継続を望んでいる可能性が高い。そこで、仲間期間設定手段５６は、申請した第１のプレイヤとそれを承認した第２のプレイヤとのレベル関係の条件が同じであれば、復活により仲間関係が成立した場合の仲間期間を、初めて仲間関係が成立した場合の仲間期間よりも長くすることが望ましい。例えば、２人のプレイヤのレベル関係に基づいて、初めて仲間関係が成立した場合の仲間期間が５日間に設定されるのであれば、同じレベル関係の条件で復活により仲間関係が成立した場合には、仲間期間が前記の２倍の１０日間に設定されようにする。
また、仲間期間設定手段５６は、申請した第１のプレイヤとそれを承認した第２のプレイヤとのレベル関係の条件が同じであれば、仲間関係復活の回数が多い程、仲間期間をより長く設定することが望ましい。
また、仲間関係の復活を何度も繰り返しているプレイヤ同士は、仲間関係が自動的に解除されることを望んでいない可能性が極めて高いと考えられる。そこで、仲間期間設定手段５６は、所定回数以上（例えば３回以上）、仲間関係の復活が実行された２人のプレイヤについては、仲間期間を設定しない（または、仲間期間を無制限とする）ことが望ましい。
次に、仲間期間を自動延長することができるゲーム管理装置の構成例を、図３９の機能ブロック図を参照しながら説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。本実施の形態のゲームサーバ１（ゲーム管理装置）は延長手段６１を備えている。この延長手段６１は、仲間期間が設定されている２人のプレイヤの少なくとも一方から相手のプレイヤに対して、仲間期間が終了するまでに所定回数（または所定回数以上）の交流処理が実行された場合に、当該仲間期間を延長する機能を有する。この延長手段６１は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。
仲間になったプレイヤ間で交流が持たれないということは、お互いに相手への関心が希薄であると考えられる。一方、仲間同士で交流を行っている場合には、プレイヤが仲間関係の維持を望んでいる可能性が高いと考えられる。そこで、仲間期間が終了するまでに条件を満たす交流があった場合に、仲間期間を自動的に延長し、仲間関係が継続されるようにするのである。
そして、延長手段６１は、仲間期間が延長された２人のプレイヤの少なくとも一方から相手のプレイヤに対して、延長された仲間期間が終了するまでに所定回数の交流処理が実行される毎に、仲間期間を延長することを繰り返すようになっている。これにより、条件を満たす交流を継続的に行っている仲間同士については、仲間期間の自動延長が繰り返されることにより仲間関係が継続して維持される。
延長の対象となる交流については、前述の挨拶、メッセージの送信、プレゼント、協力対戦の助っ人依頼、合同練習など、仲間のプレイヤ同士で行われる様々な交流を含めることができる。また、挨拶は延長の対象とはせず、メッセージの送信、プレゼント、協力対戦の助っ人依頼、合同練習のみを延長の対象とするといったように、ゲーム内に用意された複数の交流から一部の交流のみを延長の対象としてもよい。
また、２人のプレイヤの少なくとも一方から相手のプレイヤに対しての所定回数の交流があったことを、延長の条件とする。この条件を満たす形態には、いずれか一方から相手に対して所定回数の交流があれば条件を満たすとする形態と、両者とも互いに相手に対して所定回数の交流を行うことを条件とする形態とを含む。何れの形態を延長の条件として設定してもよい。特に、従来の課題であるところの、上位レベルのプレイヤにとって、仲間のプレイヤのレベルが自分よりも低い場合に、ゲームにおける協力対戦等について不公平感が生じていたということをより積極的に解消するために、少なくとも下位レベルのプレイヤが上位レベルのプレイヤに対して、所定回数またはそれ以上の交流を行うことを条件とすることが望ましい。
また、仲間期間が終了するまでに「所定回数」の交流処理が実行されたことを延長の条件とすることに関し、「所定回数」として任意の回数を設定可能である。例えば、この所定回数を１回としてもよいし、２回以上の複数回としてもよい。
また、相対的にゲームレベルが低いプレイヤから相手のプレイヤに対して交流処理が実行される場合の所定回数Ｎ１は、相対的にゲームレベルが高いプレイヤから相手のプレイヤに対して交流処理が実行される場合の所定回数Ｎ２よりも多い設定とすることが望ましい。一例としては、前記所定回数Ｎ１を３回とし、前記所定回数Ｎ２を２回とする。そして、いずれか一方から相手に対して前記所定回数の交流があれば延長条件を満たすものとする。または、両者とも互いに相手に対して前記所定回数の交流があれば延長条件を満たすものとする。
この構成によれば、レベルの異なる２人のプレイヤが仲間になった場合、下位レベルのプレイヤは上位レベルのプレイヤとの仲間関係を維持するためには、上位レベルのプレイヤよりも多くの回数の交流を必要とする。よって、上位レベルのプレイヤは、下位レベルのプレイヤとの仲間関係を終了させ易くなることから、自分好みの仲間グループをより構築し易くなる。
また、延長手段６１が、プレイヤ間のレベル差に応じて延長の条件を満たすための交流の所定回数を設定する構成としてもよい。この場合、相対的にゲームレベルが低いプレイヤから相手のプレイヤに対して交流処理が実行される場合の所定回数Ｎ１を、両プレイヤ間のレベル差Ｄが大きいほど多い設定とすることが望ましい。一例としては、レベル差Ｄが２９以下であれば所定回数Ｎ１を３回、レベル差Ｄが３０〜６９であれば所定回数Ｎ１を４回、レベル差Ｄが７０〜９９であれば所定回数Ｎ１を５回、レベル差Ｄが１００以上であれば所定回数Ｎ１を６回とする。これにより、下位レベルのプレイヤは上位レベルのプレイヤとのレベル差が大きいほど、仲間関係を維持するために多くの回数の交流を必要とする。よって、上位レベルのプレイヤにとっては、レベルが離れた下位レベルのプレイヤほど仲間関係を終了させ易くなる。
逆に、相対的にゲームレベルが高いプレイヤから相手のプレイヤに対して交流処理が実行される場合の所定回数Ｎ２を、両プレイヤ間のレベル差が大きいほど少ない設定としてもよい。一例としては、レベル差Ｄが２９以下であれば所定回数Ｎ２を３回、レベル差Ｄが３０〜６９であれば所定回数Ｎ２を２回、レベル差Ｄが７０以上であれば所定回数Ｎ２を１回とする。これにより、上位レベルのプレイヤから下位レベルのプレイヤへ交流を行なうのであれば、レベル差が大きいほど少ない回数の交流で仲間関係を容易に維持できるようになる。
上記のように、延長手段６１がプレイヤ間のレベル差に応じて延長の条件を満たすための交流の所定回数を設定する構成において、延長手段６１がプレイヤ間のレベル差の変動を検出したとき、変動後のレベル差に応じた所定回数に再設定するようにしてもよい。これにより、プレイヤ間のレベル差変動に追従して、延長の条件を満たすための交流の所定回数を適切に調整することができる。
ここで、延長手段６１が延長する期間の長さについては、一定の期間とすることができる。延長期間の長さを一定期間とする場合、例えば、１週間、１０日間、２週間等、任意の期間を設定可能である。なお、延長の期間の長さは一定期間に限定されるものではない。例えば、延長が行われる毎にランダムに延長の期間を決定してもよい。また、交流回数によって延長の期間を変動させる（交流回数が多いほど延長の期間を長く設定する）構成であってもよい。あるいは、仲間期間設定手段５６がプレイヤ間のレベル差に基づいて決定した仲間期間（仲間期間記憶手段５６ａが記憶している仲間期間）と同じ期間を、延長手段６１が延長の期間として設定してもよい。
あるいは、延長手段６１が延長処理を実行するときのプレイヤ間のレベル差に基づいて、延長の期間を設定する構成にすることもできる。例えば、図３３に例示したプレイヤ間のレベル差と仲間期間との関係を表すテーブルを、プレイヤ間のレベル差と延長の期間との関係を表すテーブルとして援用（または共用）し、延長処理実行時のプレイヤ間のレベル差に応じた延長の期間を、当該テーブルに基づいて取得するようにする。もちろん、プレイヤ間のレベル差と延長の期間との関係を表す専用のテーブルを別途用意して、ゲームサーバ１の記憶手段（ＲＡＭ１３または補助記憶装置１４等）に記憶しておいてもよい。この構成の場合、延長処理が実行される毎に、その都度、延長処理実行時のプレイヤ間のレベル差に基づいた適切な延長の期間を設定することができる。
また、延長手段６１が延長処理実行時のプレイヤ間のレベル差に基づいて、延長の期間を設定する構成において、延長手段６１がプレイヤ間のレベル差の変動を検出したとき、変動後のレベル差に応じた延長の期間に再設定するようにしてもよい。これにより、プレイヤ間のレベル差変動に追従して、延長の期間を適切に調整することができる。
延長手段６１による延長処理の実行は、データベースサーバ２に記憶されている仲間期間の情報を、延長後の情報に更新する等により行うことができる。例えば、延長手段６１は、図４２に示すように、仲間期間記憶手段５６ａが記憶仲間情報ＩＤと対応づけて記憶している仲間期間終了予定時間を、延長後の日付に更新することにより、延長処理を実行する。このとき、仲間情報ＩＤと対応づけて、延長処理実行時の時間情報として仲間期間を延長した日等を併せて記憶する。延長処理実行時の時間情報としては、年、月、日、時、分、秒等の時間情報を記憶するが、ここで記憶する時間の単位は任意に設定できる。また、延長された仲間期間の情報管理のために、仲間情報ＩＤと対応づけて、延長フラグを設定するようにしてもよい。
延長手段６１による処理形態の１つとしては、仲間期間の途中で延長条件を満たす毎に、仲間期間の延長処理を実行する形態がある。この形態の延長処理について、図４４を参照して、以下に説明する。なお、図４４およびそれ以降のフローチャートは、仲間関係にある２人のプレイヤを対象としたゲームサーバ１の処理の流れを示すものであり、ゲームサーバ１が管理している全ての仲間同士のペアに対して同様の処理が行われることになる。
図４４に示すように、延長手段６１は、２人のプレイヤに設定された仲間期間が終了する前に（Ｓ２８１でＮＯ）、交流に関する延長条件が達成されたか否かを判定する（Ｓ２８２）。例えば、この判定は、図４２に示す仲間期間の情報（仲間期間終了予定時間等）、および図４３に示すプレイヤの交流履歴の情報に基づいて行うことができる。すなわち、データベースサーバ２には、各プレイヤの交流履歴が記憶されているので、仲間期間が設定されてから仲間期間が終了するまでに（または、仲間期間が延長されてから延長された仲間期間が終了するまでに）、延長条件として定められた所定回数の交流をプレイヤが行った状態を検出可能である。
交流に関する延長条件が達成された場合（Ｓ２８２でＹＥＳ）、延長手段６１は、仲間期間の延長処理を実行する（Ｓ２８３）。例えば、図４２に示す仲間期間終了予定時間を、延長後の日付に更新する。このとき、延長処理実行時の時間情報を記憶（または更新）する。
ここで、具体的な延長例を挙げる。１月１日に設定された仲間期間が例えば７日間（１月７日まで）であり、３日目の１月３日に交流の延長条件が達成された場合、１月３日の時点で例えば７日間の延長が発生し、仲間期間の終了日は１月７日（現終了日）から７日後の１月１４日になる。よって、１月３日の時点での仲間期間の残期間（残日数）は１１日間になる。例えば、その後、１月６日に交流の延長条件が再度達成された場合、１月６日の時点で７日間の追加延長が発生し、仲間期間の終了日は１月１４日（現終了日）から７日後の１月２１日になる。よって、１月６日の時点での仲間期間の残期間は１７日間になる。
この延長例の場合、交流に関する延長条件が連続して早期に達成されると、仲間期間の残期間は増加する傾向にある。例えば、短期間に多数の交流を行って仲間期間の残期間が急激に増加した場合を考えると、その後交流が長期間途絶えた場合でも、仲間関係が長期間維持されることになる。そこで、仲間期間の残期間に上限を設けてもよい。例えば、仲間期間の残期間の上限を３０日に設定すれば、３０日以上交流に関する延長条件が満たされなければ、仲間期間は終了してしまう。よって、仲間関係を維持するためには、最長３０日の期間以内に交流に関する延長条件を満たすことが必要となり、長期間交流が途絶えているのに仲間関係が維持されることを回避できる。
そこで、Ｓ２８３の後、延長手段６１は、仲間期間の残期間が上限を超えている場合（Ｓ２８４でＹＥＳ）、仲間期間の残期間を上限に制限する（Ｓ２８５）。すなわち、図４２に示す仲間期間終了予定時間を、仲間期間の残期間の上限に合致する日付に更新する。
延長後の仲間期間の残期間が上限を超えていない場合（Ｓ２８４でＮＯ）、または仲間期間の残期間を上限に制限した後（Ｓ２８５）、Ｓ２８１に戻り、以降、仲間期間が終了するまでＳ２８１〜Ｓ２８５の処理が繰り返される。
ここで、他の具体的な延長例を挙げる。１月１日に設定された仲間期間が例えば７日間（１月７日まで）であり、３日目の１月３日に交流の延長条件が達成された場合、１月３日の時点で例えば７日間の延長が発生するのであるが、仲間期間の終了日は１月３日（延長発生日）から７日後の１月１０日になる。よって、１月３日の時点での仲間期間の残期間は７日になる。例えば、その後、１月６日に交流の延長条件が再度達成された場合、１月６日の時点で７日間の再延長が発生し、仲間期間の終了日は１月６日（延長発生日）から７日後の１月１３日になる。よって、１月６日の時点での仲間期間の残期間は７日になる。この延長例では、仲間期間の残期間は最大でも延長期間（この例では７日間）となるので、仲間期間の残期間に上限を設ける必要はない。仲間期間の残期間に上限を設けない場合は、前記Ｓ８４およびＳ８５の処理を省くことができる。
また、交流に関する延長条件を満たすことなく仲間期間が終了した場合（Ｓ２８１でＹＥＳ）、仲間関係解除手段５７により仲間関係が自動的に解除され（Ｓ２５５）、仲間関係が解除されたことが２人のプレイヤの端末装置３に報知される（Ｓ２５６）。このＳ２５５およびＳ２５６の詳細は、図３６において説明したとおりである。
このように、仲間関係にある２人のプレイヤに対して設定された仲間期間は、交流に関する所定の延長条件を満たす毎に延長される。そして、前述の仲間期間報知手段５８は、仲間期間（延長された場合、延長後の仲間期間）を表示させるための情報を、プレイヤの端末装置３へ送信し、プレイヤに仲間期間を報知する機能を有する。よって、各プレイヤは、図３５に例示する仲間リスト画面で、自分の各仲間プレイヤとの間に設定されている仲間期間（延長後の仲間期間）がいつまでなのかを確認できるようになっている。そして、プレイヤは、仲間関係を終了させたくない仲間プレイヤについては、仲間リストで確認した仲間期間が終了するまでに延長条件を満たす交流を行うことにより、仲間関係を継続できる。このように、プレイヤの端末装置３に表示される仲間リスト画面に仲間期間（延長後の仲間期間）の情報を含めることにより、プレイヤ自身による仲間管理を容易にすることができる。
延長手段６１による処理形態としては、仲間期間の終了時刻に延長条件を満たしているか否かを判定し、延長条件を満たしている場合に仲間期間の延長処理を実行する形態もある。換言すれば、設定されている仲間期間の全期間の経過を待って延長の要否を判定し、延長処理を実行する形態である。この形態の延長処理について、図４５を参照して、以下に説明する。
延長手段６１は、２人のプレイヤに設定された仲間期間の終了時刻になったときに（Ｓ２９１でＹＥＳ）、交流に関する延長条件が達成されたか否かを判定する（Ｓ２９２）。このＳ２９２の処理は、前述のＳ２８２と同様の処理である。
交流に関する延長条件を満たしている場合（Ｓ２９２でＹＥＳ）、延長手段６１は、仲間期間の延長処理を実行する（Ｓ２９３）。一方、交流に関する延長条件を満たしていない場合（Ｓ２９３でＹＥＳ）、仲間期間の終了に伴い、仲間関係解除手段５７により仲間関係が自動的に解除され（Ｓ２５５）、仲間関係が解除されたことが２人のプレイヤの端末装置３に報知される（Ｓ２５６）。
上記のように、本実施の形態の構成では、プレイヤが仲間復活申請や仲間継続申請のような特別な操作を行うことなく、ゲーム内で仲間同士が延長条件を満たす交流を楽しむだけで自動的に仲間期間が延長され、仲間関係を継続できるようになっている。特に、ソーシャルゲーム等のプレイヤの操作の容易化・簡素化が強く求められるゲームサービスを提供する場合には、特別な操作を要することなく仲間関係を継続できる本構成が好適である。
一方、延長条件を満たすような交流が行われなかった場合、お互いの関心が希薄であり、交流を楽しめるような仲間同士ではなかったということが考えられる。この場合、仲間期間が延長されることなく仲間期間の終了により仲間関係が自動的に解除されるので、やはり仲間解除のための特別な操作は不要である。
また、本実施の形態では、仲間期間の延長の概念を、仲間との交流を楽しむというソーシャル要素を取り入れたゲームに導入したことにより、現実世界の仲間関係（対人関係）に近い関係を、ゲーム内で仮想的に実現できる。すなわち、現実世界では、仲間（知り合い）になってから継続的に交流が保たれていればその仲間関係は維持されるが、一旦仲間になっても、その後、あまり交流が持たれなかった場合には、両者が親密な関係を構築できないまま仲間関係は自然消滅する。そして、本実施の形態では、交流が持たれたときの仲間関係の維持を仲間期間の延長およびその繰り返しにより実現し、交流が持たれなかった場合の仲間関係の自然消滅を、仲間期間の延長がなされないまま仲間期間が終了することによる仲間関係の自動解消により実現している。
一方、従来では、仲間関係を解除する操作が必要である等の理由により、全く交流がない又は殆ど交流がない仲間であっても、仲間として維持しているケースが殆どであり、現実世界の仲間関係とゲーム内の仲間関係とは大きく乖離しているのが現状である。
本実施の形態の構成を適用したゲームでは、プレイヤが仲間と交流を持ちながら普通にゲームをプレイしてさえいれば、実際に交流を楽しんでいる仲間で構成された仲間グループが自然に構築されることになる。
ところで、延長手段６１による仲間期間の延長が何度も繰り返されているプレイヤ同士は、仲間関係が自動的に解除されることを望んでいない可能性が高いと考えられる。そこで、延長手段６１は、仲間期間が終了するまでに所定回数（または所定回数以上）の交流があった場合に仲間期間を延長する延長処理に加え、仲間期間の延長処理自体が所定回数以上（例えば３回以上）実行された２人のプレイヤに対しては、仲間期間を無制限にする（換言すれば、仲間期間を無期限に延長する）ことが望ましい。但し、下位のプレイヤが上位のプレイヤに対して一方的に交流を行った結果として仲間期間の延長処理が所定回数以上実行された場合までを含めて、仲間期間を無制限にすると、上位プレイヤから不満が出る可能性もある。そこで、この場合、２人のプレイヤの両方とも互いに相手に対して所定回数（または所定回数以上）の交流を行うことを延長の条件とすることが望ましい。両方とも互いに相手に対して所定回数以上の交流があった場合に仲間期間の延長処理が実行され、この延長処理が所定回数以上繰り返されるということは、お互いに継続的に仲間関係を維持したいと考えていることが想定されるためである。
なお、２人のプレイヤの仲間期間を無制限にするということは、仲間関係が自動的に解除されることがない状態にするという観点から、２人のプレイヤに仲間期間を設けないことと実質的に同じである。よって、２人のプレイヤの仲間期間を無制限にすることには、２人のプレイヤの仲間期間の設定を解除することも含まれる。
次に、仲間関係が成立している２人に親密度というパラメータを設定し、親密度の値に応じて延長時の仲間期間を調整する構成について説明する。親密度とは、仲間関係が成立している２人のプレイヤの親密さを示すものであり、２人の友好度合い、友情の深さ、絆の深さ等として表現することもできる。
図３９に示すように、ゲームサーバ１は、親密度付与手段６２および補正手段６３を備えている。これらの手段６２および６３は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。
親密度付与手段６２は、交流手段５５により仲間関係が成立している２人のプレイヤ間で交流処理が実行された場合に、当該２人のプレイヤに対して親密度を付与する機能を有する。本実施の形態の親密度付与手段６２は、２人のプレイヤ間で交流処理が実行される毎に、所定値（例えば１ポイント）の親密度を付与するようになっている。なお、交流の内容により付与する親密度の値を変えてもよい。例えば、挨拶は１ポイント、メッセージ送信は２ポイント、プレゼントおよび対戦協力は３ポイント等としてもよい。また、本実施の形態では、２人の親密度の値に応じて、例えば５段階のランクが設けられている。例えば、親密度が０〜２４ポイントで知り合いランク、２５〜４９ポイントで友人ランク、５０〜７４ポイントで親友ランク、７５〜９９ポイントで相棒ランク、１００ポイント以上で盟友ランクとなる。
親密度付与手段６２は、親密度記憶手段６２ａを備えている。この親密度記憶手段６２ａは、例えば図４６に示すように、仲間情報を一意に識別する仲間情報ＩＤと対応づけて、２人のプレイヤに付与された親密度の値データベースサーバ２に記憶している。また、親密度のランクも併せて記憶していてもよい。
仲間同士の２人のプレイヤが交流を重ねた結果として、２人の親密度の値が高くなることから、親密度の値が高いほど、お互いに仲間関係の維持を望んでいると考えられる。そこで、親密度の値が高いほど、延長処理における仲間期間を長く設定することにより、親密度に応じた適切な仲間期間を設定することができる。
そこで、補正手段６３は、２人のプレイヤの親密度の値が高いほど、延長手段６１により延長される仲間期間（延長期間）が長くなるように補正する機能を有する。一例を挙げると、２人のプレイヤの親密度の値が知り合いランクのときに延長される仲間期間の長さをｎ（日）とした場合、友人ランクではｎ×１．５、親友ランクではｎ×２．０、相棒ランクではｎ×２．５、盟友ランクではｎ×３．０の期間補正を行う。
また、補正手段６３は、２人のプレイヤの親密度の値が閾値以上の場合（例えば、１００ポイント以上の盟友ランクに達している場合）、仲間期間を無期限に設定（すなわち仲間期間をなくす）ようにしてもよい。これは、２人のプレイヤの親密度の値が閾値以上まで高まった場合には、もはや何れのプレイヤも仲間関係の解除を望んでいない可能性が極めて高いと考えられるからである。
この親密度の値に応じて延長時の仲間期間を補正する処理について、図４７を参照して以下に説明する。
２人のプレイヤに設定された仲間期間が終了する前に（Ｓ２８１でＮＯ）、交流に関する延長条件が達成された場合（Ｓ２８２でＹＥＳ）、２人のプレイヤの親密度の値が閾値以上か否かが判定される（Ｓ３１１）。ここで、親密度の値が閾値以上の場合（Ｓ３１１でＹＥＳ）、補正手段６３は、仲間期間を無期限に設定する（Ｓ３１２）。また、親密度の値が閾値未満の場合（Ｓ３１１でＮＯ）、補正手段６３は、親密度の値に応じて延長手段６１により延長される仲間期間（延長期間）を補正する（Ｓ３１３）。すなわち、補正手段６３は、親密度の値が高いほど、延長期間が長くなるように補正する。Ｓ３１３の後、延長手段６１は、補正手段６３により補正された延長期間により仲間期間を延長する（Ｓ３１４）。また、Ｓ３１４の後は前記Ｓ８１に戻り、仲間期間が終了するか又は親密度が閾値以上になるまでループ処理（Ｓ２８１、Ｓ２８２、Ｓ３１１〜Ｓ３１４）を繰り返す。
なお、仲間期間が終了した場合は（Ｓ２８１でＹＥＳ）、仲間関係解除手段５７により仲間関係が自動的に解除され（Ｓ２５５）、仲間関係が解除されたことが２人のプレイヤの端末装置３に報知される（Ｓ２５６）。
〔他の実施の形態〕
特に上述のように仲間関係が自動解除される構成では、プレイヤの過去の仲間プレイヤが累積的に増加し易い。そこで、仲間関係が解除された時間条件を指定して過去の仲間プレイヤを抽出して表示できるようにする構成について説明する。
仲間情報記憶手段５４ａは、仲間関係が解除された２人のプレイヤを関係付けた過去の仲間情報とともに、当該２人のプレイヤの仲間関係が解除された時間情報も記憶装置（データベースサーバ２）に記憶する。例えば図１１Ａまたは図１１Ｂに例示するように、仲間情報記憶手段５４ａは、仲間情報ＩＤまたは過去の仲間情報ＩＤと対応づけて、仲間解除時間（仲間関係が解除された日付等）を記憶する。
そして、前記仲間履歴送信手段１０１は、プレイヤが操作する端末装置３からの仲間関係が解除された時間の条件を指定した要求に応じて、仲間情報記憶手段５４ａに記憶されている当該プレイヤの過去の仲間情報のうち前記条件を満たす情報を読み出し、当該プレイヤの過去の仲間プレイヤであって前記条件を満たす過去の仲間プレイヤを表示させるための情報を当該端末装置３へ送信する。
この構成により、プレイヤは過去の仲間リストを要求する操作を行う場合に、仲間関係が解除された時間条件を指定すれば、例えば１か月以内に仲間関係が解除された過去の仲間プレイヤのみを端末装置３に表示させたり、ＸＸ年ＸＸ月に仲間関係が解除された過去の仲間プレイヤのみを表示させたり等が可能となる。このように、仲間関係が解除された時間条件により絞り込み表示ができれば、特に過去の仲間が多くなった場合の操作性が向上する。
次に、累積増加する過去の仲間情報を保持するための記憶容量を削減するための構成について説明する。仲間情報記憶手段５４ａは、２人のプレイヤの仲間関係が解除されてから少なくとも所定期間（例えば１年間）、当該２人のプレイヤを関係付けた過去の仲間情報を保持する。そして、仲間履歴送信手段１０１は、プレイヤが操作する端末装置３からの要求に応じて、仲間情報記憶手段５４ａに記憶されている当該プレイヤの過去の仲間情報のうち仲間関係解除後に前記所定期間（例えば１年間）を経過していない過去の仲間プレイヤの情報を読み出して当該端末装置３へ送信する。
これにより、仲間関係の解除後における過去の仲間関係の情報の保持期間を、所定期間（例えば１年間）に限定することができる。プレイヤにとって、過去の仲間プレイヤとの仲間関係が解除されてから所定期間、例えば、１年間が経過してから、当該過去の仲間プレイヤと再度仲間関係を構築しようと考えることは、あまり無いと考えられる。そこで、仲間関係解除後、所定期間を経過していない過去の仲間プレイヤだけをプレイヤの端末装置３に表示させるようにすれば、仲間関係の解除後における過去の仲間情報の保持期間を、所定期間に限定することができる。これにより、累積増加する過去の仲間情報を保持するための記憶容量を大幅に削減することができる。
また、上述の実施の形態では、ゲーム実行プログラムがゲームサーバ１側に実装されており、各プレイヤの端末装置３における入力操作に応じて、ゲームサーバ１がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置３へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明した。これはいわゆるクライアントサーバ型のゲームシステムであるが、これに限定されるものではない。例えば、ゲームサーバ１が、プレイヤの仲間情報を含むゲーム情報を管理し、ゲーム内での仲間管理等のゲームサービスをプレイヤに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはプレイヤの端末装置側にて行われるゲームシステムにも本発明の実施の形態に係るゲーム管理装置、ゲーム管理方法及びプログラムを適用できる。
すなわち、ゲーム実行プログラムの一部または全部をプレイヤの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも適用できる。例えば、プレイヤの端末装置が、インターネット通信、無線ＬＡＮ通信、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信、または有線ＬＡＮ通信などにより他のプレイヤの端末装置とピア・ツー・ピア接続し、ピア・ツー・ピア型のゲームを実行することも可能である。
よって、プレイヤの端末装置としては、ゲームサーバ（ゲーム管理装置）に接続して仲間管理等のゲームサービスの提供を受けることができる様々なものが適用でき、前述の携帯電話端末、スマートフォン、ＰＨＳ端末、携帯情報端末（ＰＤＡ）、パーソナルコンピュータ、タブレット型コンピュータ以外にも、ネットワーク接続機能を有している家庭用ビデオゲーム装置（家庭用ビデオゲーム機を家庭用テレビジョンに接続することによって構成されるゲーム装置）や、携帯型のゲーム専用装置なども適用可能である。
また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等）、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてゲームサーバ１のＣＰＵ１１により実行される。また、プログラムをゲームサーバ１に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。
１ ゲームサーバ（ゲーム管理装置）
２ データベースサーバ（ゲーム管理装置）
３ 端末装置
４ ネットワーク
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 補助記憶装置
５１ ゲーム情報管理手段
５１ｂ レベル情報記憶手段（ゲームレベル記憶手段）
５２ ゲーム進行手段
５４ 仲間管理手段
５４ａ 仲間情報記憶手段
５５ 交流手段
５５ｅ 対戦協力手段
５５ｆ 交流履歴記憶手段
５６ 仲間期間設定手段
５６ａ 仲間期間記憶手段
５７ 仲間関係解除手段
５８ 仲間期間報知手段
１０１ 仲間履歴送信手段
１０２ 仲間復活申請手段
１０３ 仲間成立ポイント付与手段
１０４ 復活時間記憶手段
１０５ 再復活制限手段

Claims (8)

  1. 各プレイヤの端末装置と通信し、プレイヤ同士が仲間関係を構築することができるゲームの仲間管理を行うゲーム管理装置であって、
    仲間関係成立中の２人のプレイヤを関係付けた仲間情報を記憶するとともに、当該２人の仲間関係が解除された後も、当該２人のプレイヤを関係付けた過去の仲間情報を保持する仲間情報記憶手段と、
    プレイヤが操作する端末装置からの要求に応じて、前記仲間情報記憶手段に記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する仲間履歴送信手段と、
    前記仲間履歴送信手段が送信した情報を受信して前記プレイヤの過去の仲間プレイヤを表示している前記端末装置にて当該過去の仲間プレイヤを選択する操作が行われた場合に、当該操作の情報を前記端末装置から受信して当該プレイヤから当該過去の仲間プレイヤへの仲間関係復活の申請処理を実行する仲間復活申請手段と、を備えるゲーム管理装置。
  2. 前記仲間情報記憶手段は、仲間関係にある２人のプレイヤの一方が仲間関係を自主的に解除した場合、当該２人のプレイヤのうち仲間関係を自主的に解除した側のプレイヤと、相手から仲間関係を自主的に解除された側のプレイヤと、を区別して記憶しており、
    前記仲間履歴送信手段は、プレイヤが操作する端末装置からの要求に応じて、前記仲間情報記憶手段に記憶されている当該プレイヤの過去の仲間情報のうち当該プレイヤが仲間関係を自主的に解除した場合の情報を読み出し、当該プレイヤが仲間関係を自主的に解除した過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する請求項１に記載のゲーム管理装置。
  3. 仲間申請をしたプレイヤおよび当該申請を承認したプレイヤの２人のプレイヤ間で仲間関係が成立したときに、少なくとも承認した側のプレイヤに対して仲間成立ポイントを付与する仲間成立ポイント付与手段をさらに備え、
    前記仲間成立ポイント付与手段は、前記仲間復活申請手段が実行した前記仲間関係復活の申請処理による仲間申請を承認した前記過去の仲間プレイヤに対して付与する前記仲間成立ポイントを、前記仲間関係復活の申請処理によらない通常の仲間申請を承認したプレイヤに対して付与する前記仲間成立ポイントよりも高くする請求項１または２に記載のゲーム管理装置。
  4. 前記仲間復活申請手段が実行した前記仲間関係復活の申請処理による仲間申請を前記プレイヤの過去の仲間プレイヤが承認して当該２人のプレイヤ間で仲間関係が復活した場合、当該２人のプレイヤの仲間関係の復活時間の情報を記憶する復活時間記憶手段と、
    前記復活時間記憶手段に記憶されている前記２人のプレイヤの復活時間から所定期間が経過するまでは、当該２人のプレイヤ間での仲間関係の再度の復活を許可しない再復活制限手段と、をさらに備えている請求項３に記載のゲーム管理装置。
  5. 前記仲間復活申請手段が実行した前記仲間関係復活の申請処理による仲間申請を前記プレイヤの過去の仲間プレイヤが承認して当該２人のプレイヤ間で仲間関係が復活した場合、当該２人のプレイヤの仲間関係の復活時間の情報を記憶する復活時間記憶手段をさらに備え、
    前記仲間履歴送信手段は、前記復活時間記憶手段に記憶されている前記２人のプレイヤの復活時間から所定期間が経過するまでは、当該２人のプレイヤの仲間関係が再度解除された場合であっても、当該２人のプレイヤのうちの一方のプレイヤが操作する端末装置からの要求に応じて過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信するときに、送信する情報の中に他方のプレイヤの情報を含めない請求項３に記載のゲーム管理装置。
  6. 仲間関係が成立している２人のプレイヤに対して、プレイヤ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段と、
    仲間関係が成立している２人のプレイヤに対して設定された前記仲間期間の終了により、当該２人のプレイヤの仲間関係を自動的に解除する仲間関係解除手段と、をさらに備える請求項１に記載のゲーム管理装置。
  7. 各プレイヤの端末装置と通信し、プレイヤ同士が仲間関係を構築することができるゲームの仲間管理を行うゲーム管理装置におけるゲーム管理方法であって、
    前記ゲーム管理装置が、仲間関係成立中の２人のプレイヤを関係付けた仲間情報を記憶するとともに、当該２人の仲間関係が解除された後も、当該２人のプレイヤを関係付けた過去の仲間情報を保持する仲間情報記憶ステップと、
    前記ゲーム管理装置が、プレイヤが操作する端末装置からの要求に応じて、前記仲間情報記憶ステップによって記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置へ送信する仲間履歴送信ステップと、
    前記仲間履歴送信ステップが送信した情報を受信して前記プレイヤの過去の仲間プレイヤを表示している前記端末装置にて当該過去の仲間プレイヤを選択する操作が行われた場合に、前記ゲーム管理装置が、当該操作の情報を前記端末装置から受信して当該プレイヤから当該過去の仲間プレイヤへの仲間関係復活の申請処理を実行する仲間復活申請ステップと、を備えるゲーム管理方法。
  8. コンピュータを請求項１ないし６の何れか１項に記載のゲーム管理装置として動作させるためのプログラムであって、前記コンピュータを前記ゲーム管理装置が備えている各手段として機能させるためのプログラム。

JP2011289991A 2011-12-28 2011-12-28 ゲーム管理装置、ゲーム管理方法及びプログラム Active JP5124044B1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2011289991A JP5124044B1 (ja) 2011-12-28 2011-12-28 ゲーム管理装置、ゲーム管理方法及びプログラム
PCT/JP2012/068400 WO2013099336A1 (ja) 2011-12-28 2012-07-19 ゲーム管理装置、ゲームシステム、ゲーム管理方法、プログラム及び記録媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011289991A JP5124044B1 (ja) 2011-12-28 2011-12-28 ゲーム管理装置、ゲーム管理方法及びプログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2012237333A Division JP5225496B1 (ja) 2012-10-26 2012-10-26 ゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラム

Publications (2)

Publication Number Publication Date
JP5124044B1 true JP5124044B1 (ja) 2013-01-23
JP2013138729A JP2013138729A (ja) 2013-07-18

Family

ID=47692886

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011289991A Active JP5124044B1 (ja) 2011-12-28 2011-12-28 ゲーム管理装置、ゲーム管理方法及びプログラム

Country Status (2)

Country Link
JP (1) JP5124044B1 (ja)
WO (1) WO2013099336A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013138888A (ja) * 2013-03-12 2013-07-18 Konami Digital Entertainment Co Ltd ゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラム
JP2014144083A (ja) * 2013-01-28 2014-08-14 Taito Corp ゲーム装置

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020185392A (ja) * 2020-06-03 2020-11-19 グリー株式会社 ゲームプログラム、ゲーム処理方法および情報処理装置
CN112688856B (zh) * 2020-12-11 2023-04-07 上海掌门科技有限公司 一种解除好友关系的方法与设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006279814A (ja) * 2005-03-30 2006-10-12 Dowango:Kk 通信システム、サーバ、プログラムおよび通信方法
JP2009288995A (ja) * 2008-05-29 2009-12-10 Hitachi Ltd ソーシャルネットワーキングサービス「友人関係」管理機能
JP2010198097A (ja) * 2009-02-23 2010-09-09 Nec Corp 情報処理システム、情報処理方法および情報処理プログラム
JP5452055B2 (ja) * 2009-03-31 2014-03-26 株式会社バンダイナムコゲームス ネットワークシステム、サーバ、プログラム、及び情報記憶媒体
JP5468822B2 (ja) * 2009-06-10 2014-04-09 株式会社タイトー 対戦ゲームシステム及びゲームサーバ
JP5373507B2 (ja) * 2009-08-26 2013-12-18 株式会社Ｏｋｉソフトウェア 情報処理システム、情報処理方法およびプログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014144083A (ja) * 2013-01-28 2014-08-14 Taito Corp ゲーム装置
JP2013138888A (ja) * 2013-03-12 2013-07-18 Konami Digital Entertainment Co Ltd ゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラム

Also Published As

Publication number Publication date
JP2013138729A (ja) 2013-07-18
WO2013099336A1 (ja) 2013-07-04

Similar Documents

Publication Publication Date Title
JP5108141B1 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP5165097B1 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP5080673B1 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP5167390B2 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP5108142B1 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP6808898B2 (ja) サーバ装置の制御方法、サーバ装置、ゲームシステム及びプログラム
JP5514292B2 (ja) ゲーム管理装置及びプログラム
JP5869470B2 (ja) ゲーム管理装置及びプログラム
JP5145466B1 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP5124044B1 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP2013075189A5 (ja)
JP5145468B1 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP5124682B1 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP5253680B2 (ja) ゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラム
JP5174986B1 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP5492970B2 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP5956945B2 (ja) ゲーム管理装置、ゲームシステム及びプログラム
JP5209141B1 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP5145467B1 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム
JP5225496B1 (ja) ゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラム
JP2013138888A5 (ja)
JP5209144B1 (ja) ゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラム
JP5492969B2 (ja) ゲーム管理装置、ゲーム管理方法及びプログラム

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151102

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5124044

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250