(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0023】
以下に本発明の実施形態を説明する。以下では、理解を容易にするため、ゲーム用のサーバ装置を利用して本発明に係るゲームシステムが実現される実施形態を説明するが、以下に説明する実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。したがって、当業者であればこれらの各要素もしくは全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。
【実施例1】
【0024】
図1は、本実施形態に係るゲームシステムを実現するためのハードウェア構成を示す説明図である。以下、本図を参照して説明する。
【0025】
本図に示すように、ゲームシステム101は、1台もしくは複数のサーバ装置102からなり、サーバ装置102は、インターネットや携帯電話通信網などのコンピュータ通信網103を介して端末104に通信可能に接続される。
【0026】
サーバ装置102が複数用意されている場合は、各サーバ装置102は、自律的に、あるいは、負荷分散装置(図示せず)の制御によって、適宜負荷分散を行う。
【0027】
サーバ装置102は、所定のサーバ用プログラムをコンピュータが実行することによって実現される。
【0028】
一般に、コンピュータにおいては、ハードディスクやフラッシュメモリ等の不揮発性記憶装置に記録されたプログラムを、CPU(Central Processing Unit)が読み出して、各種の計算や解釈を行うことにより、各種の処理が実行される。これらのプログラムは、DVD−ROM(Digital Versatile Disk Read Only Memory)等の非一時的な情報記録媒体から、ハードディスク等にインストールされる。
【0029】
また、コンピュータが実行する処理において、計算に一時的に必要となる情報は、RAM(Random Access Memory)等の高速な情報記憶装置に格納される。
【0030】
このほか、コンピュータはNIC(Network Interface Card)等を介してコンピュータ通信網103に接続され、ユーザが利用する端末104と通信する。
【0031】
本実施形態においては、プログラムを実行することにより、CPUは、端末104を介して、ゲームに参加しているユーザからの操作指示等を受け付け、当該操作指示に基づいて当該ゲームそのものの進行パラメータや、当該ゲームにおけるユーザの各種パラメータを更新し、更新後の各種パラメータに基づいて、当該ゲームの現在の進行状況を知らせる情報を端末104に送って、当該ゲームに参加中のユーザに知らせる、という処理を繰り返す。
【0032】
端末104は、ユーザからの操作指示の入力の受付と、ゲームの進行状況を知らせるための画像表示や音声出力等の役割を担うことになる。
【0033】
端末104は、ユーザが使用する携帯電話やスマートフォン、PDA(Personal Data Assistance)、ゲーム端末、各種のコンピュータ等により構成される。端末104が、ウェブブラウザに相当する機能を提供している場合には、ウェブサーバとして機能するサーバ装置102を利用すれば、ゲームシステム101を実現することができる。
【0034】
また、端末104では、そのゲーム専用のクライアントプログラムを実行し、サーバ装置102では、そのゲーム専用のサーバプログラムを実行することによって、ゲームシステム101を実現しても良い。
【0035】
なお、サーバ用コンピュータに対して直接、管理者が指示を行う場合には、サーバ用コンピュータに接続されたキーボードやマウスを利用し、処理の結果を直接確認する場合には、サーバ用コンピュータに接続されたディスプレイに表示させるのが典型的であるが、管理者は、NICを介して接続された端末104から指示を行い、当該端末104に処理結果を表示させるような態様を採用しても良い。
【0036】
図2は、本実施形態に係るサーバ装置102の概要構成を示す説明図である。以下、本図を参照して説明する。
【0037】
本実施形態に係るサーバ装置102は、上記のように、1台もしくは複数のコンピュータが、サーバ用プログラムを実行することにより実現される。
【0038】
なお、ゲームシステム101は、サーバ装置102と、端末104と、から構成される。この場合には、サーバ装置102に通信可能に接続されるコンピュータがウェブブラウザ等の端末用プログラムを実行することにより、端末104として機能することになる。
【0039】
また、各ユーザがサーバ装置102を直接アクセス可能な態様では、独立した端末104を設けることなく、サーバ装置102単独でゲームシステム101を構成することができる。
【0040】
ここで、本図に示すように、サーバ装置102は、ユーザ間の友人関係を構築可能なゲームを提供し、記憶部201、要求受付部202、問合せ送付部203、回答受付部204、更新部205、応答送付部206を備える。
【0041】
また、本図に示すように、サーバ装置102は、典型的には、照会受付部207、選定部208、返答送付部209をさらに備えるが、これらの要素は省略が可能である。
【0042】
記憶部201は、サーバ用コンピュータが有するハードディスクやフラッシュディスクなど、不揮発的な記憶装置によって実現されるのが最も一般的である。
【0043】
要求受付部202、問合せ送付部203、回答受付部204、応答送付部206、照会受付部207、返答送付部209は、サーバ用コンピュータが有するNICがCPUの制御下で動作することにより実現される。なお、これらの要素には、ユーザが使用する端末用コンピュータが通信可能に接続されており、ユーザの操作指示を受け付けたり、ユーザに各種の情報を提示したりする。
【0044】
更新部205、選定部208は、ハードディスク等やNICとの間で情報を読み書きするCPUによって実現される。
【0045】
以下、各部の機能について説明する。
【0046】
まず、記憶部201には、友人関係にあるユーザ同士が対応付けて記憶される。たとえば、ユーザ名pのユーザとユーザ名qのユーザとが友人関係にある場合に、ユーザ名pとユーザ名qを対応付けてハードディスク等に記憶する手法としては、たとえば、以下のようなものが考えられる。
(1)ユーザ名p、qを文字コード順や辞書順にソートして並べた列を、可変長配列等にそのまま記憶するか、あるいは、当該列を連想配列のキーに採用する。
(2)各ユーザのゲームパラメータの一部として、友人関係にあるユーザのユーザ名を記憶する。この態様では、ユーザ名pのユーザのゲームパラメータ内の友人関係パラメータにユーザ名qが含まれる場合には、必ず、ユーザ名qのユーザのゲームパラメータ内の友人関係パラメータにユーザ名pが含まれるように、CPUが記憶部201の管理を行う。
【0047】
以下では、理解を容易にするため、ユーザ名pのユーザとユーザ名qのユーザとが対応付けて記憶され、両ユーザが友人関係にある旨が記憶されていることを、「p、qの対が記憶される」と呼ぶこととする。
【0048】
なお、ゲームの種類によっては、現実世界よりも気軽に友人関係を結んだり解消したりできる方が良い場合もある。このようなときには、友人関係に期限(友人関係が満了する日時、もしくは、友人関係が満了するまでの現在からの猶予期間)を、可変長配列の各要素に含まれるレコードの一つとしたり、連想配列にキーを与えることによって識別される要素としたり、友人関係パラメータに期限のフィールドを設ける等の手法により、期限管理を行うことができる。
【0049】
なお、記憶部201は、本実施例のように、サーバ装置102の内部に用意されるのが一般的であるが、上記のように、友人関係に関する情報の読み書きの管理ができれば、機能としては十分である。すなわち、記憶部201を実現する記憶媒体そのものは、サーバ装置102の外側に配置されていても良い。
【0050】
たとえば、実際の情報を記憶するための場所として、端末104が有するメモリカードやハードディスク等を採用した場合には、サーバ装置102は、CPUがNICを介して端末104と通信して情報の読み書きを行うこととなり、記憶部201は、端末104に用意されていることになる。
【0051】
以下では、第1ユーザが、第2ユーザに対して友人関係を結ぶよう依頼をする状況を考える。このような状況が開始されるためには、第1ユーザが第2ユーザの存在そのものを何らかの手段で知得する必要がある。これには、第1ユーザがすでに知っている他のユーザに紹介してもらう、ゲームのランキングから知得する、サーバ装置102のマッチングによって紹介される、など、種々の態様を採用することが可能である。
【0052】
図3は、本発明の実施形態に係るゲームシステム101における通信の様子を示すセッション図である。
【0053】
まず、サーバ装置102の照会受付部207は、第1ユーザから、第2ユーザの情報を求める照会301を受け付ける。
【0054】
ここで、照会301とは、第2ユーザの存在を知った第1ユーザが、当該第2ユーザの詳細情報を確認するためのものであり、この詳細情報を確認してから、友人関係を結ぶための依頼が行われる。
【0055】
すると、サーバ装置102の選定部208は、第2ユーザに関連する情報であって第1ユーザに提示すべき情報を選定し、返答送付部209は、選定された情報を示す返答302を第1ユーザに送付する。
【0056】
一般には、返答302には、第2ユーザのユーザ名やゲームパラメータの概要などの情報が含まれ、第1ユーザが使用する端末104の画面に、第2ユーザの情報が提示される。
【0057】
図4は、ユーザの照会によって得られる情報が画面に表示される表示例を示す説明図である。以下、本図を参照して説明する。
【0058】
画面401には、第2ユーザがゲームのプレイ中に使用するアバター(キャラクター)の外観の画像が表示されるアバター領域402、第2ユーザのゲームパラメータの概要が表示されるパラメータ領域403などのほか、第2ユーザに友人関係の成立を求める要求をするための要求ボタン404や、その他の各種操作を行うための入口となるメニューボタン405が用意されている。本例では、第2ユーザの名前は「ジョン」になっている。
【0059】
上記のように、端末104は、ウェブブラウザに準じた操作体系を採用して、ゲームを進めるように構成することが可能である。携帯電話に塔載されるウェブブラウザでは、電話で用いられるキーパッドをボタン操作のショートカットとして採用することができる。たとえば、キー「5」の押圧によって要求ボタン404が選択され、キー「*」の操作によってメニューボタン405が選択される、等である。これらの操作は、以下に説明する他の状態においても共通させることが望ましい。
【0060】
このほか、マウスやタブキーなどを利用して画面に表示されている操作対象からいずれかを選択する態様では、カーソルで各種ボタンを指定してからマウスでクリックしたり、リターンキーを押圧操作することで、要求ボタン404等を操作するようにしても良い。
【0061】
さて、第1ユーザが要求ボタン404を選択すると、端末104からサーバ装置102へ要求303が送られる。
【0062】
なお、後述するように、要求ボタン404を選択した後に、第2ユーザ宛の各種のメッセージ等第1ユーザが入力、選択等できるようにして、これらの情報を要求303に添付することが望ましい。
【0063】
そして、要求受付部202が、第1ユーザから、第2ユーザとの友人関係の成立を求める要求303を受け付ける。
【0064】
要求303が受け付けられると、第1ユーザと第2ユーザとが対応付けて記憶部201に記憶されていなければ、問合せ送付部203は、第2ユーザへ、要求303を承認するか拒否するかを問い合わせる問合せ304を送付する。
【0065】
なお、現在第2ユーザもサーバ装置102にアクセスしてゲームをプレイしている場合には、問合せ304は、リアルタイムに伝達することも可能である。
【0066】
ただし、一般的な電子メールの送受と同様に、サーバ装置102内に第2ユーザ宛の問合せ304等、種々のメッセージを蓄積しておき、第2ユーザがサーバ装置102にログインした時点でこれらのメッセージを第2ユーザに提示する、あるいは、第2ユーザの明示の操作があってからメッセージを第2ユーザに提示する、等の手法を採用しても良い。
【0067】
図5は、ユーザに対する問合せにおいて情報が画面に表示される表示例を示す説明図である。以下、本図を参照して説明する。
【0068】
図4に示す表示例と同様に、画面501には、第1ユーザがゲームのプレイ中に使用するアバター(キャラクター)の外観の画像が表示されるアバター領域502、第1ユーザのゲームパラメータの概要が表示されるパラメータ領域503などのほか、第1ユーザからのメッセージが表示されるメッセージ領域504が配置されている。メッセージ領域504には、第1ユーザが要求ボタン404を選択した際に入力もしくは選択したメッセージが表示される。本例では、第1ユーザの名前は「マリア」になっており、第1ユーザからのメッセージとして「ジョンさん、友達になってください」が表示されている。
【0069】
また、第1ユーザからの要求303を受け入れて、第1ユーザとの友人関係を成立させるための承認ボタン505、第1ユーザからの要求303を拒否して、第1ユーザとの友人関係を成立させないための拒絶ボタン506、その他の各種操作を行うための入口となるメニューボタン507が用意されている。
【0070】
携帯電話で操作する場合には、キー「5」を承認ボタン505に割り当て、キー「*」をメニューボタン507に割り当てて、
図4に示す状況と操作体系を共通化することが望ましい。一方、拒絶ボタン506は、これらとは異なるキー、たとえば「0」キーに割り当てる等が考えられる。
【0071】
第2ユーザが承認ボタン505や拒絶ボタン506を選択すると、第2ユーザが使用する端末104からサーバ装置102へ回答305が送られる。この回答305には、ユーザが承認ボタン505と拒絶ボタン506のいずれを選択したかに応じて、承認もしくは拒絶が指定される。
【0072】
さて、サーバ装置102において、回答受付部204は、第2ユーザから、問合せ30
4に対する回答305を受け付ける。
【0073】
回答305が受け付けられると、回答305に承認が指定されていれば、更新部205は、第1ユーザと第2ユーザとの対が追加されるように、記憶部201を更新する。
【0074】
これによって、第1ユーザと第2ユーザとの友人関係が成立したことになる。
【0075】
なお、友人関係の解消は、第1ユーザや第2ユーザの明示の操作指示によって可能である。また、後述するように、友人関係に期限が設けられている場合には、当該期限までの猶予期間が尽きることによって、友人関係が解消される。
【0076】
友人関係の解消は、最も単純には、記憶部201から第1ユーザと第2ユーザとの対を削除することによって行われるが、たとえば当該対が無効である旨のフラグ情報を追加することにより、「対の削除」を表現することとしても良い。
【0077】
さらに、回答305が受け付けられると、応答送付部206は、第1ユーザへ、回答305に指定された承認もしくは拒否を示す応答306を送付する。
【0078】
応答306は、第2ユーザから第1ユーザへのメッセージとして伝達され、第1ユーザにリアルタイムで、第1ユーザのログイン時に、あるいは、第1ユーザの明示的な操作によって第1ユーザに提示される。
【0079】
この後は、第1ユーザが使用する端末104とサーバ装置102との間で、適宜ゲーム進行のための通信311が行われる。
【0080】
なお、第1ユーザから第2ユーザ宛のメッセージ307が第1ユーザが使用する端末104からサーバ装置102へ送られると、その内容を引き写したメッセージ308が、サーバ装置102から第2ユーザが使用する端末104へと送られる。第2ユーザから第1ユーザ宛のメッセージ309は、同様に、サーバ装置102によって中継されて、メッセージ310として第1ユーザに到着する。
【0081】
なお、本図においては、第2ユーザのゲーム進行のための通信は、図示を省略しているが、第1ユーザの場合と同様に、サーバ装置102と第2ユーザが使用する端末102との間で、通信が行われる。
【0082】
図6は、サーバ装置102において実行されるゲーム制御処理の制御の流れを示すフローチャートである。以下、本図を参照して説明する。
【0083】
本処理は、サーバ装置102においてサーバ用プログラムがCPUに実行されることにより、開始される。
【0084】
本処理が開始されると、CPUは、まず、各種の初期化を行う(ステップS601)。
【0085】
そして、CPUは、NICを制御して、端末104から送られるパケットの受信を試行する(ステップS602)。この試行には、所定のタイムアウト時間を設けることが望ましい。
【0086】
ついで、CPUは、試行の結果、すなわち、パケットの受信の可否ならびに受信がされた場合には、そのパケットの種類を調べる(ステップS603)。以下、当該パケットを送ってきたユーザを、「ユーザp」とする。
【0087】
パケットが、ユーザqの照会301であれば(ステップS603;qを照会)、CPUは、ハードディスク等からユーザqの情報を取得して(ステップS604)、当該取得された情報に基づいてユーザpに提示すべきユーザqの情報を選定して、返答302を生成し(ステップS605)、NICを制御して、返答302をユーザpに送り(ステップS606)、ステップS602に戻る。
【0088】
一方、パケットが、ユーザqへの友人関係成立の要求303であれば(ステップS603;qへ要求)、CPUは、ユーザpからの友人関係成立の要求を受け入れるか否かを問い合わせるユーザq宛の問合せ304を生成し(ステップS607)、NICを制御して、問合せ304をユーザqに送り(ステップS608)、ステップS602に戻る。
【0089】
さらに、パケットが、ユーザrとの友人関係成立の可否を示す回答305であり(ステップS603;rへ回答)、回答305が、友人関係の成立を承認する旨のものであれば(ステップS621;Yes)、CPUは、ユーザpとユーザrとの友人関係を表す対をハードディスク等に追加する(ステップS609)。さらに、回答305に基づいてユーザr宛の応答306を生成し(ステップS610)、NICを制御して、この応答306をユーザrに送って(ステップS611)、ステップS602に戻る。なお、友人関係の成立を拒絶する旨のものであれば(ステップS621;No)、ステップS610に進む。
【0090】
そして、パケットが、ユーザs宛のメッセージ307であれば(ステップS603;sへメッセージ)、CPUは、受信されたパケットからユーザsに送付すべきメッセージ308を生成し(ステップS612)、NICを制御して、メッセージ308をユーザsに送って(ステップS613)、ステップS602に戻る。
【0091】
このほか、パケットが、ゲームを進行させるための指示であれば(ステップS603;指示)、当該指示に基づいて、ユーザpのゲームを進行させ(ステップS614)、進行させた結果を表す進行情報を生成し(ステップS615)、当該生成された進行情報をユーザpに送って(ステップS616)、ステップS602に戻る。
【0092】
ゲーム進行の際には、ユーザpと友人関係を結んでいる他のユーザの人数や、当該他のユーザのゲームパラメータを参照して、優秀な友人が多ければ多いほど、ゲームの進行が有利になるように構成することが可能である。
【0093】
また、その他の種類のパケットが受信された場合やタイムアウトとなるまでパケットが受信できなかった場合(ステップS603;その他)は、その事情に応じた処理を実行して(ステップS617)、ステップS602に戻る。
【0094】
上記の構成は、本発明の基本構成に相当するものであり、以下に説明する態様を種々採用することで、友人関係の促進をさらに図ることができる。以下、当該基本構成に追加可能な構成について、種々説明する。
【実施例2】
【0095】
本実施例は、友人関係を促進するため、上記実施例において、問合せ304に伴う第1ユーザから第2ユーザへのメッセージに工夫を施したものである。
【0096】
このメッセージは、第1ユーザから第2ユーザに宛てて、友人関係を結ぶよう呼掛けを行うためのものであり問合せ304に伴う呼掛けは、第2ユーザが要求303を承認するか拒否するかを決定するために、第2ユーザに提示される。
【0097】
すなわち、第1ユーザから第2ユーザ宛の問合せ304に伴うメッセージは、第2ユーザが使用する端末104の画面501内のメッセージ領域504に表示される。
【0098】
本実施形態では、第1ユーザが第2ユーザを呼ぶときの呼掛けを適切に設定することにより、友人関係を促進する。
【0099】
サーバ装置102において照会301が受け付けられると、選定部208は、ステップS605において、ゲームにおける第1ユーザならびに第2ユーザのゲームパラメータに基づいて、第1ユーザから第2ユーザへの呼掛けの候補を選定する。呼掛けの候補としては、以下のようなものが考えられる。
【0100】
第1は、第2ユーザに対する尊称である。友人関係を結ぶように依頼をする側は、依頼をされる側に対して敬意を表するのが一般的であることから、適切な尊称をサーバ装置102が提案するものである。
【0101】
たとえば「様」「さん」のような尊敬を表す用語を第2ユーザのユーザ名に付加したものを利用しても良いし、「閣下」「猊下」「your Highness」などのように、第2ユーザのユーザ名を使用しない尊称を利用しても良い。
【0102】
第2は、第1ユーザに対する第2ユーザの優劣の度合に基づいた第2ユーザに対する呼称である。ゲームパラメータのうち、ゲーム進行に伴って変化する数値、たとえば、レベル、ステージ、能力、経験値、体力、所持金、所持アイテム数等に基づいて比較を行うことにより、優劣の度合が決定される。
【0103】
第1ユーザに比べて第2ユーザが優れている場合には、上記第1の手法と同様の手法に
より尊称を得て、これを第2ユーザの呼称とすることができる。
【0104】
第1ユーザに比べて第2ユーザが劣っている場合には、「君」「ちゃん」などのような、気軽な関係を表す用語を第2ユーザのユーザ名に付加する等が考えられる。
【0105】
第3は、第2ユーザの属性に基づいた呼称を用いるものである。ゲームパラメータのうち、第2ユーザ本人もしくは第2ユーザのゲーム内におけるアバター(キャラクター)の性別、職業、役職等に基づいて属性が決定され、呼称が決められる。
【0106】
たとえば「将軍」「村長」「ボス」「監督」「Sir」「Ma'am」などのような呼称を採用することができる。また、これらの手法を適宜重複して利用しても良い。たとえば、第2ユーザのユーザ名が「山田」である場合「将軍」を付加して「山田将軍」を呼掛けとする等である。
【0107】
本態様は、第2ユーザが第1ユーザから尊称で呼ばれることで、友人関係成立に対する第2ユーザのモチベーションを高める効果があるとともに、呼掛けの候補がサーバ装置102で管理されるため、第1ユーザが誤って不適切な呼掛けを使ってしまうことを抑制することができる。
【0108】
さて、選定された呼掛けの候補は、返答302に指定される。このため、本実施例では、第1ユーザが使用する端末104は、第2ユーザに対する要求ボタン404が第1ユーザによって選択されると、第1ユーザに対して、候補が1つであればそれを採用するか否かを、候補が複数であればいずれを採用するかを問い合わせる。
【0109】
図7は、呼掛け候補の選択を促す画面の表示例を示す説明図である。以下、本図を参照して説明する。
【0110】
本図に示すように、第1ユーザが第2ユーザへの友人関係の成立を要求するための要求ボタン404を選択すると、第1ユーザが使用する端末104の画面401には、第1ユーザが使用することが推奨される第2ユーザへの呼掛け候補702が、複数表示されている。
【0111】
本図に示す例では、第2ユーザのユーザ名は「ジョン」である。本例では、呼掛け候補702として、
(1)「ボス」
(2)「監督」
(3)「ジョンさん」
(5)「ミスタージョン」
の4種類が表示されている。
【0112】
それぞれ、呼掛け候補702に対応付けられる数字のキーを押下することで、その呼掛け候補702が第2ユーザに対する呼掛けとして定められることになる。
【0113】
なお、本図に示す例では、ユーザの選択操作が最も容易なのは、キーパッドの中央に配置される数字キー「5」に割り当てられた「ミスタージョン」である。
【0114】
そこで、選定部208は、複数の候補を選定した場合には、どの候補がより適切か、の度合の計算も行う。そして、最も適切である候補を「既定値」とし、当該既定値を、ユーザの選択が最も楽に行えるキーに割り当てることとする。このような態様では、ユーザの利便性を向上させることができる。
【0115】
以下では、ユーザが「ジョンさん」を選択した例を採用して、説明する。
【0116】
さて、本実施形態では、第1ユーザが第2ユーザに対する呼掛けを選択すると、第1ユーザから第2ユーザへの挨拶メッセージの編集が可能となる。
【0117】
図8は、挨拶メッセージの編集を促す画面の表示例を示す説明図である。以下、本図を参照して説明する。
【0118】
第1ユーザが使用する端末104の画面401には、定型の挨拶からいずれかを選択するための挨拶候補801が表示されている。
(1)「ジョンさん、はじめまして」
(2)「よろしくお願いします、ジョンさん」
(3)「ジョンさん、素敵ですね」
(5)「ジョンさん、友達になってください」
【0119】
各挨拶候補801にも、第1ユーザにより選択された呼掛けが含まれている。
【0120】
第1ユーザが、挨拶候補801に先行する数字のキーを押下すると、当該挨拶候補801が指定された要求303が、第1ユーザが使用する端末104からサーバ装置102に送られ、サーバ装置102は、適切なタイミングで、この要求303に応じた問合せ304を、第2ユーザが使用する端末104に送ることになる。
【0121】
このように、本実施例では、要求303は、第1ユーザにより選択された呼掛けを必ず含む挨拶のメッセージを伴う。
【0122】
なお、挨拶候補801を提示してユーザに選択させるのではなく、メッセージ表示欄を表示してユーザに自由な文章を入力させることとしても良い。このような態様では、第1ユーザが使用する端末装置104は、第1ユーザから入力された挨拶のメッセージの前もしくは後に、第1ユーザにより選択された呼掛けである「ジョンさん」を、必ず付加することとして、要求303には、呼掛けが付加された挨拶のメッセージを含めることととしてから、サーバ装置102に送る。
【0123】
このように、本実施形態では、第1ユーザから第2ユーザに対して丁寧な挨拶のメッセージを送ることによって、第1ユーザから第2ユーザへの友人関係成立の要求が承認される可能性を高くすることができる。
【0124】
なお、第1ユーザが第2ユーザに対する呼掛けとして選択した呼称は、ゲームが進行した後でも利用することが可能である。たとえば、ゲームの進行中に、第1ユーザが、第2ユーザへ、メッセージを伝達したいと考えたとする。
【0125】
第1ユーザから第2ユーザ宛のメッセージ307が、第1ユーザの使用する端末104からサーバ装置102に送られると、サーバ装置102は、第1ユーザが選択した呼掛けをメッセージ307の冒頭や最後に付加したメッセージ308を生成する。
【0126】
サーバ装置102がこのメッセージ308を第2ユーザ宛に送ることで、第2ユーザに対する第1ユーザの丁寧な態度が第2ユーザに伝わる。このため、第2ユーザの第1ユーザとの友人関係をこのまま維持しようとするモチベーションを高めることが可能となる。
【0127】
ここで、第1ユーザから第2ユーザ宛のメッセージには、常に第1ユーザが選択した呼掛けを付加することとしても良いし、たとえば乱数を用いて、所定の確率で呼掛けが付加されることとしても良い。
【0128】
このような態様を採用する場合には、サーバ装置102は、第1ユーザが定めた第1ユーザから第2ユーザに対する呼掛けを、両ユーザの友人関係に対応付けて、記憶部201に記憶しておき、メッセージの中継の際に、適宜この情報を参照すれば良い。
【実施例3】
【0129】
本実施例は、友人関係を維持できる期限に制限を設けることにより、友人関係の解消と成立の頻度を増加させるものである。
【0130】
上記のように、友人関係には期限を設定することが可能であり、記憶部201において、この期限は、友人関係が満了する日時そのもの、もしくは、現時点から友人関係が満了する日時までの猶予期間により表現される。
【0131】
友人関係が満了する日時から、現時点の日時を減算すれば、猶予期間を算出することができ、現時点の日時に猶予期間を加算すれば、友人関係が満了する日時を得ることができる。したがって、2つの表現形式は、実質的には等価である。
【0132】
ただし、猶予期間の表現形式を採用した場合には、更新部205は、適切なタイミングで猶予期間を減らす必要がある。たとえば、更新部205は、1日に1回、猶予期間を24時間減算すれば良い。
【0133】
なお、猶予期間が0以下となった場合、すなわち、友人関係が満了する日時よりも現時点が後になった場合には、更新部205は、当該対を記憶部201から削除する。この削除処理によって、友人関係が解消される。
【0134】
本実施例の理解を容易にするため、まず、友人関係を維持できる期限の制限について、具体的な数字をあげて説明し、その後に、より一般的な説明を行う。
【0135】
ユーザは、たとえば20日等の所定の上限値を持分として有しており、この持分を、友人関係を結ぶ他のユーザに割り当てることができる。たとえば、ある時点で、ユーザPが友人関係を維持できる残りの期間が、
(1)ユーザXとは、あと5日間、
(2)ユーザYとは、あと4日間、
(3)ユーザZとは、あと3日間、
(4)ユーザWとは、あと8日間
である場合、5+4+3+8=20であり、上限値まで持分を割り当て済みであるので、新たなユーザと友人関係を結ぶことはできない。
【0136】
このまま1日が経過すると、ユーザPが友人関係を維持できる期間は、
(1)ユーザXとは、あと4日間、
(2)ユーザYとは、あと3日間、
(3)ユーザZとは、あと2日間、
(4)ユーザWとは、あと7日間
となり、4+3+2+7=16であるから、上限値までの余裕が4日間あることになる。したがって、この段階で「新たなユーザVと、4日間友人関係を結ぶ」「新たなユーザVと、3日間友人関係を結び、新たなユーザUと、1日間友人関係を結ぶ」などの方策をとることが可能となる。
【0137】
なお、新たな友人関係を結ばないままさらに2日間が経過すると、ユーザZとの友人関係は解消され、ユーザPが友人関係を維持できる期間は、
(1)ユーザXとは、あと2日間、
(2)ユーザYとは、あと1日間、
(3)ユーザWとは、あと5日間
となり、2+1+5=8であるから、余裕は12日間ある。この状態では、たとえば、「ユーザWとの友人関係を7日間継続し、新たなユーザVと、3日間友人関係を結び、新たなユーザUと、2日間友人関係を結ぶ」などの対応をとることができる。
【0138】
このように、友人関係を結ぶことができる期間の余裕は、時間の経過と現在の友人数に基づいて増えていく。このため、誰とどの期間友人関係を構築するかにつき、ユーザ自身の好みや状況に応じた適切な戦略を探ることで、友人関係を維持したり、新たな友人を探したり、友人関係を復活したり、という楽しみを得ることもできる。
【0139】
以下、ある日時tにおいて、ユーザpと友人関係にある他のユーザの集合をF(t,p)と表記する。また、ある日時tにおけるユーザpとユーザqの友人関係の猶予期間を、A(t,p,q)と表記する。なお、日時tにおいて、ユーザp,q間に友人関係が成立していない場合には、
A(t,p,q) = 0
であるものとする。
【0140】
たとえば、上記の数値例の最後の段階の時点をuとすると、
F(u,P) ={X,Y,W};
A(u,P,X) = 2;
A(u,P,Y) = 1;
A(u,P,W) = 5;
A(u,P,Z) = 0;
A(u,P,V) = 0;
A(u,P,U) = 0
となる。
【0141】
上記のように、友人関係が成立しているユーザp,qの対に対しては、猶予期間A(t,p,q)もしくはこれと実質的に等価な情報が対応付けて記憶部201に記憶されている。
【0142】
猶予期間A(t,p,q)そのものを記憶部201に記憶する態様では、更新部205は、適切なタイミングでこの値を減算する。一方、ユーザp,q間の友人関係が満了する日時C(p,q)を記憶部201に記憶する態様では、
A(t,p,q) = max(C(p,q)-t,0)
のように、満了日時C(p,q)と現在時刻tから、猶予期間A(t,p,q)を計算することができる。
【0143】
さて、ユーザpが結んでいる友人関係における猶予期間の総和は、
Σq∈F(t,p) A(t,p,q)
のように計算することができる。
【0144】
本実施例では、この総和に制限を課す。すなわち、所定の上限値Tを設けて、任意のユーザpに対して、
Σq∈F(t,p) A(t,p,q)≦T
が成立するように、猶予期間に制限を課すのである。本実施例では、任意のユーザpは、上記の制限の下で、友人関係を戦略的に構築する必要がある。
【0145】
上記の時点uの数値例では、
T = 20;
Σq∈F(u,P) A(u,P,q) = A(u,P,X)+A(u,P,Y)+A(u,P,W) = 2+1+5 = 8
となる。
【0146】
ここで、日時tにおいて、ユーザpがユーザqと新たに友人関係を結ぼうと考えたものとする。すなわち、日時tでは、ユーザpとユーザqとの間に友人関係は成立していない。すると、
F(t,p)∩{q} = φ,{p}∩F(t,q) = φ
が成立する。すなわち、日時tでは、qはpの友人の集合F(t,p)には含まれないし、pはqの友人の集合F(t,q)には含まれない。
【0147】
日時tにおいて、ユーザpが新たに友人関係を結ぶことができる猶予期間の最大値B(t,p)は、
B(t,p) = T - Σs∈F(t,p) A(t,p,s)
である。
【0148】
また、ユーザqが新たに友人関係を結ぶことができる猶予期間の最大値B(t,q)は、
B(t,q) = T - Σs∈F(t,q) A(t,q,s)
である。
【0149】
したがって、ユーザpがユーザqに対して友人関係の成立の要求をしようと考える状況下では、ユーザp,q間の友人関係に設定できる猶予期間の上限D(t,p,q)は、
D(t,p,q) = min(B(t,p),B(t,q))
となる。
【0150】
本実施例では、サーバ装置102が、日時tにおいて、第1ユーザpから第2ユーザqの照会301を受け付けると、サーバ装置102は、猶予期間の上限値D(t,p,q)を計算する。
【0151】
そして、D(t,p,q)>0であれば、計算結果D(t,p,q)とともに、第2ユーザqとの友人関係を結ぶことが可能である旨を返答302に指定する。
【0152】
一方、D(t,p,q)≦0であれば、第2ユーザqとの友人関係を結ぶことはできない旨を返答302に指定する。
【0153】
返答302を受け取った第1ユーザpの端末104は、返答302に基づいて、第2ユーザqとの友人関係を結ぶことができるか否かを、第1ユーザpに提示する。
【0154】
たとえば、
図4に示すように、要求ボタン404を表示すれば、第1ユーザpに、第2ユーザqとの友人関係を結ぶことができる。
【0155】
このほか、
図4に示すパラメータ領域403等に、友人関係を結ぶことができる上限の期間を提示することとしても良い。
【0156】
以下では、第2ユーザpとの友人関係を結ぶことができない場合の第1ユーザpへの提示
の手法を説明する。
【0157】
図9は、ユーザの照会によって友人関係を結ぶことができない旨が画面に表示される表示例を示す説明図である。以下、本図を参照して説明する。
【0158】
本図に示す表示例は、
図4とほぼ同様であるが、要求ボタン404のかわりに「友人不可」との注意書き901が表示されている。第1ユーザpは、要求ボタン404を操作することができないから、第2ユーザqに対して友人関係の成立を要求することはできないことになる。
【0159】
さて、友人関係を結ぶことができる場合に戻り、説明を続ける。第1ユーザpは、第2ユーザqとの友人関係を維持したい期間を設定する必要がある。
【0160】
本実施例では、第1ユーザpが要求ボタン404を操作した後に、期間を選択させることとする。
【0161】
図10は、友人関係を維持したい期間の選択をユーザに求めるための表示例を示す説明図である。以下、本図を参照して説明する。
【0162】
本図に示すように、画面401には、以下のような、数字キーにより操作可能な操作候補902が表示されている。
(1)「増やす」
(3)「減らす」
(5)「日に決定」
【0163】
数字キー「1」「3」は、期間領域903に表示されている数値を増減させるためものであり、期間領域903に表示されている数値は、第1ユーザpが友人関係を結ぶことを希望する日数を意味する。
【0164】
数字キー「1」を押し続けると、期間領域903に表示されている数値は、返答302に指定された上限に至るまで、増え続ける。
【0165】
数字キー「3」を押し続けると、期間領域903に表示されている数値は、所定の下限値(典型的には定数「1日」とする。)に至るまで、増え続ける。
【0166】
数字キー「5」を操作すると、期間領域903に表示されている数値が、第1ユーザpにより選択された日数となり、この日数により表される期間が、サーバ装置102に送られる要求303に指定されることになる。
【0167】
なお、各種のメッセージの入力と同様に、キーパッド等を利用した文字入力によって期間を入力することとしても良い。また、本例では、期間を選択しているが、友人関係が満了する期日を入力するようにしても良い。
【0168】
このようにして、要求303に指定された期間は、問合せ304に指定されて、サーバ装置102から第2ユーザqが使用する端末104に送られる。
【0169】
上記実施例と同様に、第2ユーザqの端末104は、問合せ304が送られると、
図5に示すものと同様の表示を用いて、第2ユーザqの承認か拒絶かの選択を促す。この際に、第1ユーザpからの挨拶とともに、メッセージ領域504に、第1ユーザpが選択した友人関係の期間を表示する。
【0170】
すなわち、本実施例では、第2ユーザqは、第1ユーザpの要求する期間だけ友人関係を結ぶか否かのみを考えれば良い。
【0171】
なお、
図10に示すように日数の編集を可能として、第1ユーザpが希望する日数を第2ユーザqが減らせるようにしても良い。この場合には、承認を指定した回答305に、第2ユーザqが許容した日数を指定することとする。
【0172】
このようにして、第1ユーザpと第2ユーザqの間で、ある期間友人関係を維持することの合意がとれた場合には、ステップS609において、第1ユーザpが要求303において指定した期間(もしくは、第2ユーザpが回答305において許容した期間)を、対に対応付けて記憶すれば良い。
【実施例4】
【0173】
本実施例は、実施例2において参照している情報を実施例3においても参照して、友人関係の成立の促進を図る。
【0174】
一般に、携帯電話でゲームをプレイしているユーザは、決定キー(本実施例では「5」キーを採用している。)等を連打する操作を好む傾向にある。そこで、友人関係を結ぶのに適切と思われる初期値を、
図10に示す期間選定の際に提供することで、ユーザの利便性を向上させる。
【0175】
ここで、上記の通り、実施例2には、ゲームにおけるユーザの優劣に基づいて第2ユーザの呼称を決定態様があるが、本実施例では、当該優劣を、実施例3における第1ユーザの期間選択の初期値の決定に用いる。
【0176】
すなわち、本実施例では、第1ユーザpが第2ユーザqに友人関係を要求するのにふさわしい期間を、選定部208が選定する。選定された期間は、サーバ装置102から端末装置104に送られる返答302に指定される。返答302を受け付けた第1ユーザpの端末104は、第1ユーザpが要求ボタン404を操作した直後に、期間領域903に表示されるべき初期値として、返答302に指定された期間を採用するのである。
【0177】
一般に、劣っているユーザから優れているユーザに対して友人関係を結ぶことを要求する場合には、その逆の場合よりも、要求に伴う期間を控え目にする方が友人関係が成立する可能性が高くなる傾向にある。そこで、選定部208は、第1ユーザpに比べて第2ユーザqが優れていればいるほど、初期値とする期間を短くする。
【0178】
このほか、さらに詳細な統計的分析を行う方法としては、
(1)ユーザの優劣の差
(2)要求された側の猶予期間の最大値
(3)要求された期間の長さ
に対して
(4)要求が承認された割合
を分析して、ユーザの優劣の差ならびに要求される側の猶予期間の最大値から、適切な初期値を選定することとしても良い。
【0179】
本実施例によれば、ユーザの優劣の差を利用することで、友人関係が成立する可能性が高い期間を選定し、これを初期値とすることで、ユーザの利便性を図り、友人関係を促進することができるようになる。
【実施例5】
【0180】
上記実施例のように、友人関係に期限を設けることによって、第1ユーザpと第2ユーザqとの友人関係が解消した後に、第1ユーザpが第2ユーザqとの友人関係を再度要求することがある。たとえば、友人関係をそのまま継続したいと考えるときや、かつては友人関係を結んでいたが解消されて日数が経過した相手と、再び友人関係を結び直したい、と考える場合である。
【0181】
ここで、過去に第2ユーザqに対して使っていた昔の呼掛けと、再び友人関係を結ぼうとする際に第2ユーザqに対して使うべき新たな呼掛けと、には、注意を払う必要がある。
【0182】
すなわち、昔の呼掛けと、新たな呼掛けと、は、同じものを採用しても良いし、昔の呼掛けよりも新たな呼掛けを、より一層丁寧にしても良いが、新たな呼掛けが昔の呼掛けよりも失礼な文言であると、トラブルを惹起する可能性が高まる、と考えられる。
【0183】
たとえば、以前に「○○様」と呼んでいた相手を「○○さん」「○○君」「○○ちゃん」と呼び掛けて友人関係を要求すると、相手は、失礼である、と感じて、友人関係を拒絶する可能性が高くなる、と考えられる。
【0184】
また、ゲームの進行にともなって第2ユーザqのゲーム上の体力や職業、役職が変化することがある。たとえば、第2ユーザqが出世していれば、新たな役職にふさわしい呼掛けを採用した方が良い。一方、第2ユーザqが降格していたときに、新たな役職に応じた呼掛けで友人関係を要求すると、第2ユーザqは「第1ユーザpに見下された」と感じてしまい、友人関係を拒絶する可能性がある。
【0185】
2つの呼掛けX、Yのいずれがより丁寧かを定めることは、難しいことがある。しかしながら、2つの呼掛けX、Yについて、
(1)呼掛けXよりも呼掛けYは丁寧。呼掛けXは、呼掛けYより失礼。
(2)呼掛けYよりも呼掛けXは丁寧。呼掛けYは、呼掛けXより失礼。
(3)呼掛けXと呼掛けYは同程度に丁寧。
(4)呼掛けXと呼掛けYの丁寧の度合の差異は判定できない。
のいずれであるか、を定めることは可能である。すなわち、呼掛けの丁寧さには、数学における半順序関係が成立している、と考えることができる。
【0186】
そこで、本実施例では、選定部208は、第1ユーザpから第2ユーザqへの呼掛けの候補を選定する際に、以前に第1ユーザpにより選定された第1ユーザpから第2ユーザqへの呼掛けを取得する。
【0187】
そして、選定部208は、以前の呼掛けよりも、上記の半順序関係において失礼な呼掛けを避けるように、候補や既定値を選定する。
【0188】
第1の手法は、以前の呼掛けよりも失礼な呼掛けは、一切候補としない、という手法である。すなわち、上記実施例と同様の手法で呼掛けの候補を得た後に、以前の呼掛けよりも失礼な呼掛けを候補から除外する。
【0189】
第2の手法は、候補そのものは上記実施例と同様の手法で得るのであるが、上記実施例と同様にして得た候補の既定値が、以前の呼掛けよりも失礼である場合には、当該候補を既定値とするのではなく、以前の呼掛けを既定値とする。
【0190】
本実施例は、友人関係が時間の経過とともに自動的に解消される態様、特に、友人関係の解消を検知したときや解消される日が迫ったときにユーザに対してその旨を知らせ、友人関係を継続するか否かの判断を促す態様と組み合わせると効果的である。
【0191】
なお、上記の友人関係の再要求の例と同様に、友人関係が維持されている間であっても、メッセージに付加される呼掛けを更新することとしても良い。
【0192】
第2ユーザの役職やレベルが変化したり、第1ユーザと第2ユーザとの能力の差が大きく変化する等、第2ユーザの状態が変化して、選定部208が選定する第2ユーザに対する候補が変化したことが検知された場合、あるいは、定期的に、サーバ装置104は、候補や既定値を選定し直して、第2ユーザへの呼掛けを変更するかを、第1ユーザに問い合わせることとするのである。
【0193】
特に、第1ユーザが選定した呼掛けをその後のメッセージのやりとりで自動的に付加する態様では、このような呼掛けの更新を行うことで、第2ユーザとの友人関係をより一層強めることができるようになる。
【実施例6】
【0194】
上記実施例においては、ゲームシステム101は、サーバ装置102と端末104とがコンピュータ通信網103を介して通信することを前提としていた。
【0195】
しかしながら、記憶部201乃至返答送付部209の各要素は、必ずしもサーバ装置102内に設けることを要しない。
【0196】
すなわち、ゲームシステム101は、複数のユーザとのやりとりが可能であるような1台もしくは複数のコンピュータからなるように構成することが可能であり、この場合に、記憶部201乃至返答送付部209の各要素は、いずれかのコンピュータ上で実現するような態様を採用することができる。
【0197】
たとえば、端末104同士が直接もしくはコンピュータ通信網103を介してピアツーピア通信を行い、その通信にサーバ装置102が介在しない場合には、2つの端末104のいずれかが、記憶部201乃至返答送付部209の各要素を実現し、いわばサーバ装置102として機能するように構成することで、上記実施例と同様の効果を奏することができる。
【0198】
本発明の第1の観点に係るサーバ装置は、ユーザ間の友人関係を構築可能なゲームを提供し、
第1ユーザが使用する第1端末から、第2ユーザとの友人関係の成立を求める要求を受け付ける要求受付部、
前記要求が受け付けられると、ユーザ同士の友人関係が記憶される記憶部に、前記第1ユーザと前記第2ユーザとの友人関係が記憶されていなければ、前記第2ユーザが使用する第2端末へ、前記要求を承認するか拒否するかを問い合わせる問合せを送付する問合せ送付部、
前記第2端末から、前記問合せに対する回答を受け付ける回答受付部、
前記回答が受け付けられると、前記回答に承認が指定されていれば、前記第1ユーザと前記第2ユーザとの友人関係が記憶されるように、前記記憶部を更新する更新部、
前記回答が受け付けられると、前記第1端末へ、前記回答に指定された承認もしくは拒否を示す応答を送付する応答送付部
を備え、
前記問合せは、前記第1ユーザから前記第2ユーザへの呼掛けを伴い、
前記問合せに伴う呼掛けは、前記第2ユーザが前記要求を承認するか拒否するかを決定するために、前記第2端末において前記第2ユーザに提示される
ように構成する。
【0199】
本発明の第2の観点に係る端末は、ユーザ間の友人関係を構築可能なゲームを提供し、第1ユーザから、第2ユーザとの友人関係の成立を求める要求を受け付ける要求受付部、
前記要求が受け付けられると、ユーザ同士の友人関係が記憶される記憶部に、前記第1ユーザと前記第2ユーザとの友人関係が記憶されていなければ、前記第2ユーザへ、前記要求を承認するか拒否するかを問い合わせる問合せを送付する問合せ送付部、
前記第2ユーザから、前記問合せに対する回答を受け付ける回答受付部、
前記回答が受け付けられると、前記回答に承認が指定されていれば、前記第1ユーザと前記第2ユーザとの友人関係が記憶されるように、前記記憶部を更新する更新部、
前記回答が受け付けられると、前記第1ユーザへ、前記回答に指定された承認もしくは拒否を示す応答を送付する応答送付部
を備え、
前記問合せは、前記第1ユーザから前記第2ユーザへの呼掛けを伴い、
前記問合せに伴う呼掛けは、前記第2ユーザが前記要求を承認するか拒否するかを決定するために、前記第2ユーザに提示される
ように構成する。
【0200】
本発明の第3の観点に係るゲームシステムは、ユーザ間の友人関係を構築可能なゲームを提供し、
第1ユーザから、第2ユーザとの友人関係の成立を求める要求を受け付ける要求受付部、
前記要求が受け付けられると、ユーザ同士の友人関係が記憶される記憶部に、前記第1ユーザと前記第2ユーザとの友人関係が記憶されていなければ、前記第2ユーザへ、前記要求を承認するか拒否するかを問い合わせる問合せを送付する問合せ送付部、
前記第2ユーザから、前記問合せに対する回答を受け付ける回答受付部、
前記回答が受け付けられると、前記回答に承認が指定されていれば、前記第1ユーザと前記第2ユーザとの友人関係が記憶されるように、前記記憶部を更新する更新部、
前記回答が受け付けられると、前記第1ユーザへ、前記回答に指定された承認もしくは拒否を示す応答を送付する応答送付部
を備え、
前記問合せは、前記第1ユーザから前記第2ユーザへの呼掛けを伴い、
前記問合せに伴う呼掛けは、前記第2ユーザが前記要求を承認するか拒否するかを決定するために、前記第2ユーザに提示される
ように構成する。
【0201】
また、本発明のゲームシステムにおいて、
前記呼掛けは、前記第1ユーザが前記第2ユーザを呼ぶための名称、呼称もしくは尊称である
ように構成することができる。
【0202】
また、本発明のゲームシステムにおいて、
前記呼掛けは、前記ゲームにおける前記第1ユーザに対する前記第2ユーザの優劣の度合に基づいて定められる
ように構成することができる。
【0203】
また、本発明のゲームシステムにおいて、
前記第1ユーザから、前記第2ユーザの情報を求める照会を受け付ける照会受付部、
前記照会が受け付けられると、前記ゲームにおける前記第1ユーザならびに前記第2ユーザのゲームパラメータに基づいて、前記第1ユーザから前記第2ユーザへの呼掛けの候補を選定する選定部、
前記第2ユーザの情報を示す返答を前記第1ユーザに送付する返答送付部
をさらに備え、
前記返答は、前記選定された候補を伴い、
前記第1ユーザは、前記返答に伴う候補に基づいて、前記要求に伴う呼掛けを定める
ように構成することができる。
【0204】
また、本発明のゲームシステムにおいて、
前記更新部は、所定の解消条件が満たされた友人関係を、前記記憶部から削除し、
前記選定部は、以前に前記第1ユーザから前記第2ユーザへの呼掛けが定められていれば、当該以前に定められた呼掛けに基づいて、前記呼掛けの候補を選定する
ように構成することができる。
【0205】
また、本発明のゲームシステムにおいて、
前記ゲームシステムは、前記第1ユーザから前記第2ユーザへの送付されるべきメッセージに、前記呼掛けを付加する
ように構成することができる。
【0206】
本発明の第4の観点に係るゲーム制御方法は、ユーザ間の友人関係を構築可能なゲームを提供するゲームシステムが実行するゲーム制御方法であって、
前記ゲームシステムは、要求受付部、問合せ送付部、回答受付部、更新部、応答送付部を有し、
前記ゲーム制御方法は、
前記要求受付部が、第1ユーザから、第2ユーザとの友人関係の成立を求める要求を受け付ける要求受付工程、
前記要求が受け付けられると、前記問合せ送付部が、ユーザ同士の友人関係が記憶される記憶部に、前記第1ユーザと前記第2ユーザとの友人関係が記憶されていなければ、前記第2ユーザへ、前記要求を承認するか拒否するかを問い合わせる問合せを送付する問合せ送付工程、
前記回答受付部が、前記第2ユーザから、前記問合せに対する回答を受け付ける回答受付工程、
前記回答が受け付けられると、前記回答に承認が指定されていれば、前記更新部が、前記第1ユーザと前記第2ユーザとの友人関係が記憶されるように、前記記憶部を更新する更新工程、
前記回答が受け付けられると、前記応答送付部が、前記第1ユーザへ、前記回答に指定された承認もしくは拒否を示す応答を送付する応答送付工程
を備え、
前記問合せは、前記第1ユーザから前記第2ユーザへの呼掛けを伴い、
前記問合せに伴う呼掛けは、前記第2ユーザが前記要求を承認するか拒否するかを決定するために、前記第2ユーザに提示される
ように構成する。
【0207】
本発明の第5の観点に係るプログラムは、ユーザ間の友人関係を構築可能なゲームを提供するためのゲームシステムを実現し、前記プログラムは、コンピュータを、
第1ユーザから、第2ユーザとの友人関係の成立を求める要求を受け付ける要求受付部、
前記要求が受け付けられると、ユーザ同士の友人関係が記憶される記憶部に、前記第1ユーザと前記第2ユーザとの友人関係が記憶されていなければ、前記第2ユーザへ、前記要求を承認するか拒否するかを問い合わせる問合せを送付する問合せ送付部、
前記第2ユーザから、前記問合せに対する回答を受け付ける回答受付部、
前記回答が受け付けられると、前記回答に承認が指定されていれば、前記第1ユーザと前記第2ユーザとの友人関係が記憶されるように、前記記憶部を更新する更新部、
前記回答が受け付けられると、前記第1ユーザへ、前記回答に指定された承認もしくは拒否を示す応答を送付する応答送付部
として機能させ、
前記問合せは、前記第1ユーザから前記第2ユーザへの呼掛けを伴い、
前記問合せに伴う呼掛けは、前記第2ユーザが前記要求を承認するか拒否するかを決定するために、前記第2ユーザに提示される
ように機能させる。
【0208】
本発明によれば、ユーザ間の友人関係を促進するのに好適なサーバ装置、端末、ゲームシステム、ゲーム制御方法、ならびに、これらを1つ以上のコンピュータにて実現するプログラムを提供することができる。