JP2013183888A - ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム - Google Patents

Abstract

【課題】ユーザ間の仲間関係を構築する機会を逸することを少なくするようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供すること。
【解決手段】本発明のゲーム制御装置は、ユーザ間を関係付ける関係付け手段と、ゲームを実行する実行手段と、第１のユーザによる前記ゲームの実行中において、他のユーザを出現させる出現手段と、前記他のユーザが前記第１のユーザと関係付けられていない第２のユーザである場合に、第１のユーザと第２のユーザを関係付ける操作を受け入れるためのメニュー、あるいは第１のユーザと第２のユーザの関係付けを申請する操作を受け入れるためのメニューを、前記ゲーム実行中のゲーム画像に表示させる表示手段と、を備える。
【選択図】図９

Description

本発明は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御する技術に関する。

近年、特定のサービス提供者によるソーシャルネットワーキングサービス（ＳＮＳ）においてウェブブラウザ上で動作するＡＰＩ(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム（Social Game）が普及している。ソーシャルゲームは、不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは、インターネットに接続可能であって、かつウェブブラウザが搭載された通信端末を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。

上述したソーシャルゲームでは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の１つとなっている。ソーシャルゲームでは、例えば、他のユーザ（仲間）との協力プレイのほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。このようなソーシャルゲームの一例として、下記の非特許文献１に記載されたデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。

アプリＳＴＹＬＥ Vol.2（株式会社イースト・プレス）、26-27頁

従来のソーシャルゲームにおいて、ユーザは、他のユーザと仲間の関係になるために、他のユーザに対して仲間の関係になるための申請を行って、他のユーザから承諾を得るという手続きをゲームサーバが仲介している。このとき、従来、他のユーザに対して仲間の関係になるための申請を行うためのリンクを探す手間が掛かるため、ユーザは、その煩雑さを嫌って仲間の申請を行わず、仲間関係を構築する機会を逸してしまう場合があった。

本発明は上述した観点に鑑みてなされたもので、ユーザ間の仲間関係を構築する機会を逸することを少なくするようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置であって、
ユーザ間を関係付ける関係付け手段と、
ゲームを実行する実行手段と、
第１のユーザによる前記ゲームの実行中において、他のユーザを出現させる出現手段と、
前記他のユーザが前記第１のユーザと関係付けられていない第２のユーザである場合に、第１のユーザと第２のユーザを関係付ける操作を受け入れるためのメニュー、あるいは第１のユーザと第２のユーザの関係付けを申請する操作を受け入れるためのメニューを、前記ゲーム実行中のゲーム画像に表示させる表示手段と、
を備える。

「他のユーザが出現する」の出現態様は限定されず、例えば、他のユーザのゲーム上のユーザ名を含むテキストの表示や、他のユーザの画像若しくは他のユーザにより指定された画像の表示、又は他のユーザがゲーム上で使用するキャラクタの表示等を含む。

このゲーム制御装置では、第１のユーザがゲームを実行中に他のユーザが出現する構成となっている。このとき、出現した他のユーザが第１のユーザと関係付けられていない第２のユーザである場合には、両者（第１のユーザと第２のユーザ）を関係付けるためのメニューが第１のユーザによるゲームの実行中のゲーム画像に表示される。そのため、第１のユーザは、ゲームの終了後にゲームの実行中に出現した第２のユーザ宛の関係付けのための手続きに手間取ることなく、ゲームの実行中にタイムリーかつ簡便な操作で第２のユーザと関係付けを行うことができる。よって、このゲーム制御装置によれば、ユーザ間の仲間関係を構築する機会を逸することを少なくすることができる。

上記ゲーム制御装置において、前記第１のユーザと関係付けられるユーザ数は、上限値を有し、前記表示手段は、前記第１のユーザと関係付けられているユーザ数が前記上限値に満たない場合に、前記メニューを表示させてもよい。例えば仲間として関係付けるユーザ数を無制限としたならば、個々のユーザ間の関係度合いが希薄になる可能性もあるため、関係付けるユーザ数に上限値を設ける場合がある。そこで、第１のユーザと関係付けられたユーザ数が既に上限値に達している場合、前記メニューを表示しないようにすることで、第１のユーザは、出現した他のユーザと自らを関係付けることができないことを直ちに認識することができる。

上記ゲーム制御装置において、前記出現手段は、前記第１のユーザの所定のアクセス時刻前の所定時間内にアクセスした他のユーザの中からいずれかのユーザを、前記第２のユーザとして出現させてもよい。これにより、第１のユーザと同じ時間帯にゲームを実行している他のユーザが第２のユーザとして出現することになるため、第１のユーザから見ると、第２のユーザに対する親近感が湧き、積極的に仲間としての関係を構築するようになり、ゲームのソーシャル性が高まる。また、メニュー表示時に第２のユーザがゲームを実行している可能性もあるが、その場合には、仲間としての関係付けの申請（仲間申請）がゲーム実行中の第２のユーザに届くため、仲間申請を即時的に承諾してもらえる可能性が高くなる。さらに第２のプレイヤは、第１のユーザの所定のアクセス時刻前の所定時間内にゲームを実行していたユーザであることから、例えばゲームに飽きた等といった理由で実質的にゲームに参加していないユーザに対する仲間申請を抑えることができる。

上記ゲーム制御装置において、前記ゲームは、複数のエリアで構成され、前記出現手段は、前記第１のユーザと同一のエリアに位置する他のユーザの中からいずれかのユーザを、前記第２のユーザとして出現させてもよい。これにより、第１のユーザと同一のエリアでゲームを実行している他のユーザが第２のユーザとして出現することになるため、第１のユーザから見ると、第２のユーザに対する親近感が湧き、積極的に仲間としての関係を構築するようになり、ゲームのソーシャル性が高まる。
さらに、第１のユーザの所定のアクセス時刻前の所定時間内にアクセスし、かつ同一エリアでゲームを実行しているユーザの中から第２のユーザを選択するようにしてもよい。このゲームでは、第２のユーザが第１のユーザと同一エリアに出現するタイミングと、その第２のユーザが実際にそのエリアでゲームを実行しているタイミングとは一致しないが（つまり、非同期であるが）、上述したように第２のユーザを選択することで、仮に前記タイミングが一致する（つまり、同期型の）ゲームであれば同一のエリアで第１のユーザと出会っていた可能性のあるユーザの中から第２のユーザを選択できる。

上記ゲーム制御装置において、前記第１のユーザと関係付けられるユーザ数は、上限値を有し、前記表示手段は、前記第２のユーザと関係付けられているユーザ数が前記上限値に満たない場合に、前記メニューを表示させてもよい。つまり、第２のユーザと関係付けられたユーザ数が既に上限値に達している場合、前記メニューを表示しないようにする。これにより、第１のユーザは、出現した他のユーザと自らを関係付けることができないことを直ちに認識することができる。

上記ゲーム制御装置において、前記実行手段は、複数の前記ユーザが終了地点に向けてレースするゲームを実行し、前記出現手段は、前記第１のユーザが前記ゲーム実行中に前記第２のユーザを出現させてもよい。

本発明の第２の観点は、ゲーム制御装置におけるゲーム制御方法であって、
ユーザがゲームを実行するステップと、
第１のユーザによる前記ゲームの実行において、他のユーザを出現させるステップと、
前記他のユーザが前記第１のユーザと関係付けられていない第２のユーザである場合に、第１のユーザと第２のユーザを関係付ける操作、あるいは第１のユーザと第２のユーザの関係付けを申請する操作を受け入れるためのメニューを、前記ゲーム実行中のゲーム画像に表示させるステップと、
前記操作に応じて、前記第１のユーザと前記第２のユーザを関係付けるステップと、
を含む。

本発明の第３の観点は、ゲームの実行を制御するために、コンピュータに、
ユーザがゲームを実行する機能、
第１のユーザによる前記ゲームの実行中において、記憶部から他のユーザを抽出して出現させる機能、
前記他のユーザが前記第１のユーザと関係付けられていない第２のユーザである場合に、第１のユーザと第２のユーザを関係付ける操作、あるいは第１のユーザと第２のユーザの関係付けを申請する操作を受け入れるためのメニューを、前記ゲームの実行中のゲーム画像に表示させる機能、及び
前記操作に応じて、前記第１のユーザと前記第２のユーザを関係付けて前記記憶部に記憶する機能、
を実現させるためのプログラムである。

コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ−ＲＯＭやＣＤ−ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。

本発明の第４の観点は、通信端末と、当該通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置と、を含むゲームシステムであって、
ユーザ間を関係付ける関係付け手段、
ユーザがゲームを実行する実行手段、
第１のユーザによる前記ゲームの実行中において、他のユーザを出現させる出現手段、及び
前記他のユーザが前記第１のユーザと関係付けられていない第２のユーザである場合に、第１のユーザと第２のユーザを関係付ける操作、あるいは第１のユーザと第２のユーザの関係付けを申請する操作を受け入れるためのメニューを、前記ゲームの実行中のゲーム画像に表示させる表示手段
の各手段を、前記通信端末又は前記ゲーム制御装置のいずれか一方が備える。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、ユーザ間の仲間関係を構築する機会を逸することを少なくすることができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 データベースサーバに含まれるユーザデータベースの構成例を示す図。 トップページを表示する通信端末の表示画面の一例を示す図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態のゲームサーバの主要な処理の一例を示すフローチャート。

以下、本発明の実施形態について説明する。

（１）ゲームシステムの構成
図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）などの通信端末である。なお、以下の説明において、各通信端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、通信端末１０と表記する。
このゲームシステムにおいて、ゲームサーバ２０は、クライアントである通信端末１０と通信可能に構成されており、通信端末１０に対してゲーミングサービスを提供する。ゲームサーバ２０には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ３０は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ２０と有線又は無線で接続される。なお、ゲームサーバ２０とデータベースサーバ３０は、通信網ＮＷを介して接続しても良い。
通信端末１０は、ゲームサーバ２０によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末１０をウェブページ上で操作してゲームを実行する。

また、図１には図示していないが、ゲームサーバ２０とは別に各通信端末１０のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末１０からのアクセスを受け入れるために複数のゲームサーバ２０を設ける場合は、その複数のゲームサーバ２０間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ２０は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。

（２）通信端末の構成
図２及び図３を参照して通信端末１０について説明する。
図２は、通信端末１０の外観の例を示す図であって、（ａ）は、例えば折り畳み式の携帯端末（携帯電話機）などの釦入力方式の通信端末を例示したものであり、（ｂ）は、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図３は、通信端末１０の内部構成を示すブロック図である。
図３に示すように、通信端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、画像処理部１４、指示入力部１５、表示部１６、及び、信号送受信部としての無線通信インタフェース部１７を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１８が設けられている。

ＣＰＵ１１は、ＲＯＭ１２内のウェブブラウザをＲＡＭ１３にロードして実行する。そして、ＣＰＵ１１は、指示入力部１５等によってユーザに入力されるＵＲＬ(Uniform Resource Locator)の適切な指定に基づき、無線通信インタフェース部１７を介して、ゲームサーバ２０からウェブページを表示するためのデータ、すなわち、ＨＴＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ（以下、総称して適宜「ＨＴＭＬデータ」と表記する。）を無線通信インタフェース部１７を介して取得し、そのＨＴＭＬデータを解釈する。なお、通信端末１０には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。
なお、ＨＴＭＬデータの取得に当たって、ＣＰＵ１１は、予め登録されたユーザＩＤ（ユーザ識別情報）、あるいは指示入力部１５を介して入力されるユーザＩＤを含むアクセス要求メッセージを、無線通信インタフェース部１７を介してゲームサーバ２０へ通知する。

ウェブブラウザは、画像処理部１４を介して、取得したＨＴＭＬデータに基づき、ゲームサーバ２０から提供されるウェブページを表示部１６に表示する。また、ウェブブラウザは、ユーザが指示入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、その選択に応じたウェブページを表示するための新たなＨＴＭＬデータの送信（つまり、ウェブページの更新）をゲームサーバ２０へ要求する。

画像処理部１４は、ＨＴＭＬデータの解析結果としてＣＰＵ１１から与えられる表示用画像データに基づいて、表示部１６にウェブページを表示する。表示部１６は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示する。

通信端末１０が釦入力方式の通信端末（図２（ａ））である場合、指示入力部１５は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群１５ａ、及び、テンキーなどの複数の指示入力釦を含む釦群１５ｂを備え、各釦の押下（操作）入力を認識してＣＰＵ１１へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部１６に表示されているウェブページをスクロールして表示することをＣＰＵ１１へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示（例えば強調表示）されている１つのハイパーリンクまたはメニューをユーザが選択することをＣＰＵ１１へ指示するために設けられる。なお、通信端末１０を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末１０を片手で保持したままその親指で操作（クリック）しやすいように、通信端末１０の前面に配置されていることが好ましい。図２（ａ）に示す例では、釦群１５ｂは、釦群１５ａの下方に配置され、「０」〜「９」、「＊」、「＃」（テンキー）が表記された複数の指示入力釦を含む。

通信端末１０がタッチパネル入力方式の通信端末（図２（ｂ））である場合、指示入力部１５は、主として表示画面１６ａに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図２（ｂ）に示すように、通信端末１０がタッチパネル入力方式の場合であっても釦群１５ａが設けられる場合もある。

通信端末１０に表示されるウェブページ上のメニューの選択操作は、例えば通信端末１０が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末１０がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面１６ａ上のメニューの位置を指あるいはペンで指示（タッチ操作）することによって行われる。

（３）ゲームサーバの構成
図４を参照してゲームサーバ２０の構成について説明する。
ゲームサーバ２０は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末１０に対してゲームのウェブサービスを提供する。図３に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、及び、無線通信インタフェース部２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。

ＲＯＭ２２には、クライアントである通信端末１０のウェブブラウザに対してＨＴＭＬ文書や画像などのオブジェクトの表示（ウェブページの表示）のサービスを提供するアプリケーションプログラムが格納されている。ＲＯＭ２２には、アプリケーションプログラム以外にもＣＰＵ２１によって参照される各種データが格納されている。
ＣＰＵ２１は、ＲＯＭ２２内のゲームプログラムをＲＡＭ２３にロードして実行し、無線通信インタフェース部２５を介して、各種の処理を行う。

例えば、ＣＰＵ２１は、無線通信インタフェース部２５を介して、ＨＴＭＬデータを通信端末１０宛に送信する。なお、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
ＣＰＵ２１は、通信インタフェース部を介して、通信端末１０で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなＨＴＭＬデータの送信、または、ゲームサーバ２０内の演算処理あるいはデータ処理などを含む。
データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。

（４）データベースサーバの構成
データベースサーバ３０（記憶装置）は、大容量のハードディスク装置やＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。

本実施形態のゲームサーバ２０によって実現されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲームサーバ２０によって実現されるゲームの一例として、レースゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）を採り上げる。このレースゲームは、複数のユーザが終了地点に向けてレースを行う（競争する）ゲームである。

図６に、本実施形態のゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、アクセスログ、ユーザ名／表示画像、技能レベル、体力ポイント、友情ポイント、所持コイン、仲間のユーザＩＤ、及び保有アイテムのデータの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・アクセスログ
対象となるユーザＩＤに基づくログイン時刻、アクセス時刻を記録したデータである。なお、ログイン時刻は、ユーザの認証処理を含むログインを行った時刻である。アクセス時刻は、ログイン後に、ユーザＩＤに基づきゲームのウェブサービスを受けるためにゲームサーバ２０にアクセスした時刻である。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０にユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・技能レベル
ゲーム上のユーザの技能レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。
・体力ポイント
本実施形態のゲームにおいて、レースを行う上で必要となるポイントである。体力ポイントは、レースのコースを進行させることで例えば一定量減少し、所定の時間が経過する毎に回復（増加）する値である。
・友情ポイント
本実施形態のゲームにおいて、仲間へ応援メッセージを送信することでユーザが取得するポイントである。
・所持コイン
ユーザＩＤに対応するユーザがゲーム上で有料機能を利用するときに必要となるゲーム上の仮想通貨（コイン）の所持額である。所持コインは、ユーザがゲーム上で有料機能を利用したときに消費（低減）し、ユーザが、サービス提供者等に所定の方法で実際の金銭を支払うことでその支払額に応じて増加する。
・仲間のユーザＩＤ
対象となるユーザＩＤと関係付けられた他のユーザＩＤのデータである。
・保有アイテムのデータ
ユーザが保有するゲーム上で使用可能なアイテムのデータである。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、例えばレースにおけるユーザのコース上の進行度合いを示すデータや、レースの結果の履歴などのデータを含む。

（５）本実施形態のゲーム
以下、本実施形態のゲーム（本実施形態のゲーム）の内容について、図７、及び図８Ａ，８Ｂを参照しながら説明する。図７は、本実施形態のゲームにおいて通信端末１０上に表示されるトップページの一例を示す図である。図８Ａ，８Ｂは、レースが実行されるときの通信端末１０上に表示される一連のウェブページの例であるウェブページＰ１〜Ｐ５を示す図である。

図７に例示する本実施形態のゲームのトップページは、個々のユーザＩＤに応じたウェブページで構成される。図７の例では、ユーザデータ表示領域、ユーザ画像表示領域及びメニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、体力ポイント、友情ポイント、仲間の各項目のデータ（図６参照）が表示される領域である。ユーザ画像表示領域は、対象となるユーザＩＤのユーザデータに含まれるアバタ画像が表示される領域である。メニュー表示領域には、本実施形態のゲームを開始するためのメニューとして、「レース開始」と表記されたメニューｍ１が配置されている。

図７のトップページ上でゲームを開始するメニューｍ１が選択操作されると、図８ＡのＰ１に示すようにウェブページが更新される。ウェブページＰ１には、レースが行われるコースの画像が表示される表示領域２００、ユーザのコースの進行率（進行度合い）を示す進行ゲージ２１０、及び「コースを進む」と表記されたメニューｍ１０を含む。このレースは、複数のユーザが、同一地点の開始地点（START）から終了地点（FINISH）に向けて（つまり、１周を）競争するゲームである。コース上には複数のチェックポイント（ＣＰ１，ＣＰ２，…）が設けられている。

ユーザは、最初は開始地点（START）に位置しており、ゲームを実行するメニューｍ１０を操作する度に、例えば一定量の体力ポイントを消費し、コース上を所定長さあるいはランダムな長さの距離だけコースを進むことができる。コース上の進行に応じて、コース上の開始地点（START）を起点として、進行したコース上の部分が強調表示（図８Ａの例では、太線表示）され、それに伴って進行ゲージ２１０の目盛りが増加する。例えば、ウェブページＰ１上でゲームを実行するメニューｍ１０が選択操作されると、ウェブページはＰ２に示すように更新される。ウェブページＰ２では、強調表示されたコース上の線が延び、ユーザがチェックポイントＣＰ２に到達したことが分かる。ユーザが各チェックポイントに到達する度に、例えばウェブページＰ３に示すような表示を行うようにしてもよい。

このゲームでは、レースの途中で（つまり、ゲームの実行中において）、他のユーザが出現する（他のユーザと遭遇する）場合があるように構成されている。なお、出現するユーザは、このレースを必ずしも実行しているとは限らない。他のユーザが出現した場合には、図８ＢのＰ４に示すようにウェブページが更新される。ウェブページＰ４において、表示領域２００には２台の車両がすれ違う状況（つまり、出現した他のユーザと遭遇する状況）を示す画像が表示されるとともに、例えば出現したユーザのユーザ名（この場合、ＧＩＰさん）を含むテキスト２２０が表示される。さらにウェブページＰ４は、出現した他のユーザに対して、挨拶メッセージを送信するためのメニューｍ１１と、仲間に誘う、つまり仲間の関係になるための申請を行う（仲間申請する）ためのメニューｍ１２とが表示される。なお、メニューｍ１２（「仲間に誘う」）は、ユーザ間の関係付けを申請する仲間申請の操作を受け入れるためのメニューの一例である。

ここで、例えば、メニューｍ１２（「仲間に誘う」）が選択操作されると、Ｐ５に示すようにウェブページが更新され、仲間申請をするための詳細ページが表示される。ウェブページＰ５では、例えば仲間の申請先（この場合、ＧＩＰさん）へのコメントを入力するための入力フィールド２３０と、「仲間申請する」と表記されたメニューｍ１３とが含まれる。入力フィールド２３０には、デフォルトとして例えば「よろしくお願いします。」というテキストが入力されているが、ユーザは適宜他の内容のコメントに変更することができるように構成されている。メニューｍ１３（「仲間申請する」）が選択操作されると、その時点で入力フィールドに入力されているテキストを含む仲間申請のための申請メッセージが通信端末１０からゲームサーバ２０宛に送信される。この仲間申請が申請先から承諾されると、両者（この場合、ＫＮＭさんとＧＩＰさん）が仲間として登録されることになる。
なお、メニューｍ１３（「仲間申請する」）を選択操作した後、ウェブページは例えばＰ１，Ｐ２に示したようなコースの画像を含むものに更新され、引き続きユーザがレースを実行できるように構成される。

（６）ゲーム制御装置における各処理の概要
次に、上述した本実施形態のゲームを実現するためゲーム制御装置における各処理について説明する。
本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述した本実施形態のゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図９を参照して説明する。図９は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
なお、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネル操作によるウェブページのスクロール操作によって変化しうる。

登録手段５１は、例えば通信端末１０に提供するウェブページ上での通信端末１０への適切な操作入力に基づいてユーザの登録要求を認識し、登録処理を行う機能を備える。この登録処理は、ユーザが本実施形態のゲームにユーザ登録を行うときに実行される。
登録手段５１の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、無線通信インタフェース部２５を介して通信端末１０から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ２０から提供されるウェブページ上での通信端末１０に対する所定の操作（例えば、所定のメニューの選択操作やユーザが指定するユーザＩＤやパスワード等のテキスト入力等）によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末１０を特定するための情報（例えばＵＩＤ（Unique Identifier）などの端末の個体識別情報、メールアドレス等）が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザＩＤが含まれていてもよい。
ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれていない場合には、ユーザＩＤを新規に発行してそのユーザＩＤの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、そのユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末１０へ送信する。
登録が完了すると、ＣＰＵ２１は、ユーザＩＤに対応するユーザデータを生成し、ユーザデータベース３１に格納する。登録が完了すると、ユーザは、本実施形態のゲームを実行することが可能となる。

関係付け手段５２は、異なるユーザ間を関係付ける機能を備える。つまり、関係付け手段５２は、例えばユーザＩＤに基づく申請を契機として、当該ユーザＩＤを他のユーザＩＤとを関係付けて記録する。すなわち、関係付け手段５２は、ユーザＩＤに基づく申請を契機として、他のユーザＩＤ（つまり、他のユーザ）を「仲間」として記録する。
関係付け手段５２の機能は例えば、以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、無線通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（仲間申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されてもよい。また、本実施形態のゲームでは、ユーザがゲームを実行中に他のユーザが出現する場合があるが、その場合には、ＣＰＵ２１は、ゲームを実行中のユーザによる所定の操作を契機として、出現したユーザ宛の申請メッセージを受け付ける。
ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するウェブページを表示するためのＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間のユーザＩＤ」の箇所（図６参照）にデータ（相手のユーザＩＤ）を書き込む。なお、ＣＰＵ２１は、仲間申請先のユーザの承認を不要とする場合は、ゲームを実行中のユーザによる所定の操作を契機として、両者を仲間として登録しても良い。

アクセス管理手段５３は、各ユーザのログイン時の認証や、ログイン時刻、及びログイン後のアクセス時刻を含むアクセスログを管理する機能を備える。
アクセス管理手段５３の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、各ユーザの通信端末１０からのＨＴＴＰリクエストを受信すると、当該ＨＴＴＰリクエストから個体識別情報、あるいはユーザＩＤ及びパスワードを取得し、その個体識別情報、あるいはユーザＩＤ及びパスワードを、例えばユーザデータベース３１に記録済みのデータと照合して認証処理を行う。また、ＣＰＵ２１は、ログイン時、及びログイン後のアクセス（例えば、ウェブページの更新を要求するＨＴＴＰリクエストの受信）時にユーザデータにアクセスして、アクセスログのデータを更新する。
なお、ユーザがゲーム内の特定のステージや、特定のレースのコース等、ゲーム内の特定のエリアに対してアクセスする場合に、アクセス管理手段５３は、アクセス時刻を、ゲーム内のエリアと対応付けて、アクセスログとして記録してもよい。

ゲーム実行手段５４は、通信端末１０に対するユーザのウェブページ上の選択操作に応じてＨＴＴＰリクエストを受信し、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータ（つまり、ＨＴＴＰレスポンス）を送信することで、ウェブサービスによりゲームを実行する機能を備える。ゲームの内容は特に限定されるものではないが、本実施形態では、図７、及び図８Ａ，８Ｂを参照して説明したように、レースゲームを実行する場合を例としている。
本実施形態のゲームを実行する場合、ゲーム実行手段５４の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えばゲームの実行を指示するメニューｍ１０が選択操作されたことを認識すると、進行率の値を一定量、あるいはランダムな量だけ増加させ、ゲームを実行中のユーザのコース上の位置を進行率の増加分に応じて進行させるように、ゲーム画像を表示するためのＨＴＭＬデータを生成する。ＣＰＵ２１は、例えば、ユーザのコース上の位置がコースのいずれかのチェックポイントに到達した場合には、所定のテキスト（例えば図８ＡのウェブページＰ３では、「第２チェックポイント通過」というテキスト）を含むＨＴＭＬデータを生成する。なお、ゲームを実行中のユーザの進行率、及びコース上の位置は、例えばユーザごとにＲＡＭ２３に一時的に記憶される。
ＣＰＵ２１は、ゲームの実行を指示するメニューｍ１０が選択操作される度に、ユーザの体力ポイントを例えば一定量減少させ、ユーザの体力ポイントが所定の閾値より少なくなると、コースを進行させずに、例えば「体力がありません。少し休みましょう。」等といったテキストを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。この場合には、ユーザは、体力ポイントが回復するまで、コースを進行させることができない。

出現手段５５は、ユーザ（第１のユーザ）によるレースゲームの実行中において、他のユーザを出現させる機能を備える。ここで、「他のユーザ」は、ゲームを実行中のユーザと既に仲間の関係にあるユーザであっても、仲間でないユーザであってもよい。出現手段５５が出現させる他のユーザは、例えば、予め規定された所定の条件を満足するユーザとすることができる。出現手段５５が他のユーザを出現させるタイミングは定期的なタイミングであってもよいし、ランダムなタイミングであってもよい。
出現手段５５の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、例えば、ゲームを実行中のユーザ以外の他のユーザの中から、ランダムにユーザを選択し、あるいは予め規定された所定の条件を満足するユーザを選択する。このとき、ＣＰＵ２１は、ユーザデータベース３１のユーザデータを参照する。他のユーザを選択した後、ＣＰＵ２１は、任意のタイミングで、例えば図８ＢのウェブページＰ４に示したように、ゲームを実行中のユーザに対して、選択した他のユーザが出現したことを通知するＨＴＭＬデータを生成して、ゲームを実行中のユーザの通信端末１０宛に送信する。

表示手段５６は、出現させられた他のユーザがゲームを実行中のユーザ（第１のユーザ）と関係付けられていないユーザ（第２のユーザ）である場合に、第１のユーザと第２のユーザを仲間として関係付ける操作を受け入れるためのメニュー、あるいは第１のユーザと第２のユーザの仲間としての関係付けを申請する操作を受け入れるためのメニューを、ゲーム実行中のゲーム画像に表示させる機能を備える。なお、「第１のユーザと第２のユーザの仲間としての関係付けを申請する操作を受け入れるためのメニュー」は、図８ＢのウェブページＰ４の例では、メニューｍ１２（「仲間に誘う」）に相当する。
表示手段５５の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、ゲームを実行中のユーザ以外の他のユーザを選択すると、ゲームを実行中のユーザのユーザデータを参照して、選択された他のユーザがゲームを実行中のユーザの仲間であるか否かを判定する。ＣＰＵ２１は、両者が仲間でないと判定した場合には、挨拶メッセージを送信するメニューｍ１１と仲間申請を行うメニューｍ１２を表示するＨＴＭＬデータを生成し、両者が仲間であると判定した場合には、挨拶メッセージを送信するメニューｍ１１のみを表示するＨＴＭＬデータを生成する。

なお、ウェブページＰ４の例では「第１のユーザと第２のユーザを仲間として関係付ける操作を受け入れるためのメニュー」は、図示していないが、メニューｍ１２（「仲間に誘う」）に代えて、例えば「仲間にする」と表記されたメニューを表示してもよい。このようなメニューが選択操作された場合には、関係付け手段５２は、他のユーザの承諾を得ることなく、一方的に第１のユーザと第２のユーザを仲間として関係付けるようにしてもよい。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１０のフローチャートを参照して説明する。図１０は、本実施形態のゲーム制御装置によって、本実施形態のゲームのレース処理を示すフローチャートである。なお、図１０のフローチャートは、図８Ａ，８ＢのウェブページＰ１〜Ｐ５のウェブページ（ゲーム画像）に対応した処理である。図１０のフローチャートにおける各処理の実行に伴って適宜、ウェブページＰ１〜Ｐ５の各ウェブページを表示するためのＨＴＭＬデータがゲームサーバ２０から通信端末１０宛に送信されるが、ＨＴＭＬデータの送信処理はフローチャートには記載せず、ウェブページＰ１〜Ｐ５の符号のみを記載してある。

先ず、図７に示したトップページにおいてゲームの実行を指示するメニューｍ１が選択操作されたことを認識すると、ゲームサーバ２０のＣＰＵ２１は、図８ＡのＰ１に示すようにウェブページを更新するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。なお、レース開始時点では、ユーザのコース上の位置はコースの開始地点（START）であり、かつ進行率は０％となっている。このウェブページ上で、ゲームの実行を指示するメニューｍ１０が選択操作されたことを認識すると（ステップＳ１００：ＹＥＳ）、ＣＰＵ２１は、進行率の値を一定量、あるいはランダムな量だけ増加させ、ゲームを実行中のユーザのコース上の位置を進行率の増加分に応じて進行させるようにコースの画像を更新して表示するためのＨＴＭＬデータを生成する（ステップＳ１１０）。また、ＣＰＵ２１は、メニューｍ１０の選択操作に応じて、ユーザの体力ポイントを例えば一定量ずつ減少させる。つまり、このレースでは、ユーザは、メニューｍ１０の選択操作に応じて、自らの体力ポイントを消費しつつ、終了地点（FINISH）に向けてコース上を他のユーザと競争することになる。ＣＰＵ２１は、コース上のユーザの位置がコースに予め設けられているチェックポイントに到達したと判断した場合には（ステップＳ１２０：ＹＥＳ）、例えば図１８ＡのウェブページＰ３に示すように、特定のチェックポイントを通過したことを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する（ステップＳ１３０）。ユーザがコース上を１周して終了地点（FINISH）、つまりゴールに到達すると（ステップＳ１４０：ＹＥＳ）、レースは終了となるが、ゴールに到達していなければステップＳ１５０へ進む。

ＣＰＵ２１は、ユーザがレースを実行中に、所定のタイミングで、あるいはランダムなタイミングで、実行中のユーザ以外の他のユーザを出現させることを決定すると（ステップＳ１５０：ＹＥＳ）、ランダムにユーザを選択し、あるいは予め規定された所定の条件を満足するユーザを選択する（ステップＳ１６０）。次いでＣＰＵ２１は、ステップＳ１６０で選択された他のユーザがゲームを実行中のユーザの仲間であるか否かを判定する(ステップＳ１７０)。その結果、両者が仲間でないと判定した場合には（ステップＳ１７０：ＮＯ）、ＣＰＵ２１は、挨拶メッセージを送信するメニューｍ１１と仲間申請を行うメニューｍ１２を表示するＨＴＭＬデータを生成して（ステップＳ１８０）、ゲームを実行中のユーザの通信端末１０宛に送信する。一方、両者が仲間であると判定した場合には（ステップＳ１７０：ＹＥＳ）、ＣＰＵ２１は、挨拶メッセージを送信するメニューｍ１１のみを表示するＨＴＭＬデータを生成して（ステップＳ１９０）、ゲームを実行中のユーザの通信端末１０宛に送信する。

ＣＰＵ２１は、仲間申請を行うメニューｍ１２が選択操作された結果（ステップＳ２００：ＹＥＳ（ｍ１２））、仲間申請の申請メッセージを受信したときには、仲間申請処理を実行する（ステップＳ２１０）。すなわち、例えば、図８ＢのＰ５に示すようにウェブページが表示されるようにＨＴＭＬデータを生成するとともに、仲間申請のための申請メッセージを送信するメニューｍ１３の選択操作に応じて、ステップＳ１６０で選択されたユーザ宛に、ゲームを実行中のユーザから仲間申請があったことを通知する処理を行う。通知先のユーザから仲間申請に対して承諾メッセージが返信されると、ＣＰＵ２１は、ゲームを実行中のユーザと、ステップＳ１６０で選択されたユーザとを仲間として関係付ける処理を行う。
ＣＰＵ２１は、挨拶メッセージを送信するメニューｍ１１が選択操作されたことを認識したときには（ステップＳ２００：ＹＥＳ（ｍ１１））、挨拶メッセージ処理を実行する（ステップＳ２１０）。挨拶メッセージ処理では、ＣＰＵ２１は、例えば、ゲームを実行中のユーザからのコメントを入力するための入力フィールドと、送信を指示するためのメニューとを含むウェブページ（図示せず）を表示するためのＨＴＭＬデータを生成する。

なお、ステップＳ２００において、例えば一定時間いずれのメニューも選択操作されない場合、あるいは例えば図示しないメニュー（リターンメニュ）が選択操作された場合には、ステップＳ１００に戻り、ゲームの実行を指示するメニューｍ１０を含むウェブページを表示するためのＨＴＭＬデータを生成して、ゲームを実行中のユーザの通信端末１０宛に送信してもよい。また、ステップＳ２１０又はステップＳ２２０の終了後についても同様である。すなわち、ゲームを実行中のユーザは、他のユーザが出現した後に、再度コースを進むことができるように構成されている。

上述したように、本実施形態のゲーム制御装置によれば、ユーザ（第１のユーザ）がゲームを実行中に他のユーザが出現する構成となっている。このとき、出現した他のユーザがゲームを実行中の第１のユーザと関係付けられていないユーザ（第２のユーザ）である場合には、両者（第１のユーザと第２のユーザ）を関係付けるためのメニューが、第１のユーザによるゲームの実行中のゲーム画像に表示される。そのため、第１のユーザは、ゲームの終了後にゲームの実行中に出現した第２のユーザ宛の関係付けのための手続きに手間取ることなく、ゲームの実行中にタイムリーかつ簡便な操作で第２のユーザと関係付けを行うことができる。よって、このゲーム制御装置によれば、ユーザ間の仲間関係を構築する機会を逸することを少なくすることができる。
なお、本実施形態では、ユーザが実行するゲームの対象としてレースゲームを例として説明したが、実行対象となるゲームの内容は如何なるものでもよい。

（８）変形例
以下、上述した実施形態の変形例について説明する。

（８−１）変形例１
一般に、ユーザが構築できる仲間の数を無制限としたならば、個々のユーザ間の関係度合いが希薄になる可能性もあるため、仲間の数に上限値を設けてもよい。上述した実施形態において、ゲームを実行中のユーザ（第１のユーザ）の仲間の数に上限値を設けるようにした場合には、表示手段５６は、ゲームを実行中のユーザの仲間の数が上限値に満たない場合に、メニューｍ１２（図８ＢのウェブページＰ４；仲間申請を行うためのメニュー）を表示させてもよい。つまり、表示手段５６は、ゲームを実行中のユーザの仲間の数が上限値に達している場合、仲間申請を行うメニューｍ１２を表示しないようにしてもよい。これにより、ゲームを実行中のユーザは、出現した他のユーザを仲間とすることができないことを直ちに認識することができる。

この変形例は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、出現させる他のユーザを選択した後、ゲームを実行中のユーザのユーザデータを参照し、仲間の数（仲間のユーザＩＤの数）が上限値に達しているか否かを判定する。そして、ＣＰＵ２１は、その判定結果に基づいて、例えばウェブページＰ４（他のユーザが出現するウェブページ）に仲間申請を行うメニューｍ１２を表示させるか否かを決定して、対応するＨＴＭＬデータを生成する。

（８−２）変形例２
上記ゲーム制御装置において、出現手段５５は、ゲームを実行中のユーザ（第１のユーザ）の所定のアクセス時刻前の所定時間内にアクセスした他のユーザの中からいずれかのユーザ（第２のユーザ）を出現させてもよい。これにより、ゲームを実行中のユーザと同じ時間帯にゲームを実行している他のユーザ（第２のユーザ）が出現することになるため、第１のユーザから見ると、第２のユーザに対する親近感が湧き、積極的に仲間としての関係を構築するようになり、ゲームのソーシャル性が高まる。また、メニュー表示時に第２のユーザがゲームを実行している可能性もあるが、その場合には、仲間申請がゲーム実行中の第２のユーザに届くため、仲間申請を即時的に承諾してもらえる可能性が高くなる。さらに第２のプレイヤは、一定時間内にゲームを実行していたユーザであることから、例えばゲームに飽きた等といった理由で実質的にゲームに参加していないユーザに対する仲間申請を抑えることができる。

この変形例は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、出現させるユーザを選択するに当たって、ゲームを実行中のユーザのユーザデータのアクセスログを参照し、所定のアクセス時刻（例えば、最新のアクセス時刻）を読み出す。ＣＰＵ２１は次に、ゲームを実行中のユーザのアクセス時刻前の所定時間内にアクセス時刻がアクセスログに記録されているという検索条件で、条件に合う他のユーザをユーザデータを参照して検索する。ＣＰＵ２１は、検索の結果得られたユーザを、出現させるユーザとして選択する。

（８−３）変形例３
上記ゲーム制御装置において、レースゲームが複数のコースあるいはステージ（複数のエリア）で構成されている場合、出現手段５５は、ゲームを実行中のユーザ（第１のユーザ）と同一のエリアに位置する他のユーザの中からいずれかのユーザ（第２のユーザ）を出現させてもよい。これにより、ゲームを実行中のユーザと同一のエリアでゲームを実行している他のユーザ（第２のユーザ）が出現することになるため、第１のユーザから見ると、第２のユーザに対する親近感が湧き、積極的に仲間としての関係を構築するようになり、ゲームのソーシャル性が高まる。

この変形例は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、ユーザからアクセスがある度に、アクセス時刻と対応付けてアクセス対象のゲーム内のコースあるいはステージをアクセスログとして記録する。そしてＣＰＵ２１は、出現させるユーザを選択するに当たって他のユーザのアクセスログを参照し、ゲームを実行中のユーザがアクセスしているコースあるいはステージに、現在時刻に近い時刻で（例えば、所定の時間差内で）アクセスしているユーザを検索する。ＣＰＵ２１は、検索の結果得られたユーザのいずれか、又は最も近い時刻でアクセスしているユーザを、出現させるユーザとして選択する。

さらに、変形例２と変形例３を組み合わせてもよい。つまり、第１のユーザの所定のアクセス時刻前の所定時間内にアクセスし、かつ同一エリアでゲームを実行しているユーザの中から第２のユーザを選択するようにしてもよい。本実施形態のゲームでは、第２のユーザが第１のユーザと同一エリアに出現するタイミングと、その第２のユーザが実際にそのエリアでゲームを実行しているタイミングとは一致しないが（つまり、非同期であるが）、上述したように第２のユーザを選択することで、仮に前記タイミングが一致する（つまり、同期型の）ゲームであれば同一のエリアで第１のユーザと出会っていた可能性のあるユーザの中から第２のユーザを選択できる。

（８−４）変形例４
上述した実施形態において、ゲームを実行中のユーザ（第１のユーザ）の仲間のユーザ数は、上限値を有し、表示手段５６は、ゲームの実行中に出現した他のユーザ（第２のユーザ）と仲間のユーザ数が上限値に満たない場合に、メニューｍ１２（図８ＢのウェブページＰ４；仲間申請を行うためのメニュー）を表示させてもよい。つまり、他のユーザ（第２のユーザ）と仲間のユーザ数が上限値に達している場合、仲間申請を行うメニューｍ１２を表示しないようにする。これにより、第１のユーザは、出現した他のユーザと自らを関係付けることができないことを直ちに認識することができる。

この変形例は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、出現させる他のユーザを選択した後、選択したユーザのユーザデータを参照し、仲間の数（仲間のユーザＩＤの数）が上限値に達しているか否かを判定する。そして、ＣＰＵ２１は、その判定結果に基づいて、例えばウェブページＰ４（他のユーザが出現するウェブページ）に仲間申請を行うメニューｍ１２を表示させるか否かを決定して、対応するＨＴＭＬデータを生成する。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。上記実施形態及び各変形例に記載された技術的事項は適宜組合せて適用してもよい。

上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。

上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、ゲーム実行手段５４、出現手段５５、表示手段５６の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…無線通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…関係付け手段
５３…アクセス管理手段
５４…ゲーム実行手段
５５…出現手段
５６…表示手段

（３）ゲームサーバの構成
図４を参照してゲームサーバ２０の構成について説明する。
ゲームサーバ２０は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末１０に対してゲームのウェブサービスを提供する。図４に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、及び、無線通信インタフェース部２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。

上記ゲーム制御装置において、前記出現手段は、前記第１のユーザの所定のアクセス時刻前の所定時間内にアクセスした他のユーザの中からいずれかのユーザを、前記第２のユーザとして出現させてもよい。これにより、第１のユーザと同じ時間帯にゲームを実行している他のユーザが第２のユーザとして出現することになるため、第１のユーザから見ると、第２のユーザに対する親近感が湧き、積極的に仲間としての関係を構築するようになり、ゲームのソーシャル性が高まる。また、メニュー表示時に第２のユーザがゲームを実行している可能性もあるが、その場合には、仲間としての関係付けの申請（仲間申請）がゲーム実行中の第２のユーザに届くため、仲間申請を即時的に承諾してもらえる可能性が高くなる。さらに第２のユーザは、第１のユーザの所定のアクセス時刻前の所定時間内にゲームを実行していたユーザであることから、例えばゲームに飽きた等といった理由で実質的にゲームに参加していないユーザに対する仲間申請を抑えることができる。

（８−２）変形例２
上記ゲーム制御装置において、出現手段５５は、ゲームを実行中のユーザ（第１のユーザ）の所定のアクセス時刻前の所定時間内にアクセスした他のユーザの中からいずれかのユーザ（第２のユーザ）を出現させてもよい。これにより、ゲームを実行中のユーザと同じ時間帯にゲームを実行している他のユーザ（第２のユーザ）が出現することになるため、第１のユーザから見ると、第２のユーザに対する親近感が湧き、積極的に仲間としての関係を構築するようになり、ゲームのソーシャル性が高まる。また、メニュー表示時に第２のユーザがゲームを実行している可能性もあるが、その場合には、仲間申請がゲーム実行中の第２のユーザに届くため、仲間申請を即時的に承諾してもらえる可能性が高くなる。さらに第２のユーザは、一定時間内にゲームを実行していたユーザであることから、例えばゲームに飽きた等といった理由で実質的にゲームに参加していないユーザに対する仲間申請を抑えることができる。

Claims (9)

1. ユーザ間を関係付ける関係付け手段と、
   ゲームを実行する実行手段と、
   第１のユーザによる前記ゲームの実行中において、他のユーザを出現させる出現手段と、
   前記他のユーザが前記第１のユーザと関係付けられていない第２のユーザである場合に、第１のユーザと第２のユーザを関係付ける操作を受け入れるためのメニュー、あるいは第１のユーザと第２のユーザの関係付けを申請する操作を受け入れるためのメニューを、前記ゲーム実行中のゲーム画像に表示させる表示手段と、
   を備えた、ゲーム制御装置。
2. 前記第１のユーザと関係付けられるユーザ数は、上限値を有し、
   前記表示手段は、前記第１のユーザと関係付けられているユーザ数が前記上限値に満たない場合に、前記メニューを表示させることを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記出現手段は、前記第１のユーザの所定のアクセス時刻前の所定時間内にアクセスした他のユーザの中からいずれかのユーザを、前記第２のユーザとして出現させることを特徴とする、
   請求項１又は２に記載されたゲーム制御装置。
4. 前記ゲームは、複数のエリアで構成され、
   前記出現手段は、前記第１のユーザと同一のエリアに位置する他のユーザの中からいずれかのユーザを、前記第２のユーザとして出現させることを特徴とする、
   請求項１又は２に記載されたゲーム制御装置。
5. 前記第１のユーザと関係付けられるユーザ数は、上限値を有し、
   前記表示手段は、前記第２のユーザと関係付けられているユーザ数が前記上限値に満たない場合に、前記メニューを表示させることを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. 前記実行手段は、複数の前記ユーザが終了地点に向けて競争するゲームを実行し、
   前記出現手段は、前記第１のユーザが前記ゲーム実行中に前記第２のユーザを出現させることを特徴とする、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. ゲーム制御装置におけるゲーム制御方法であって、
   ユーザがゲームを実行するステップと、
   第１のユーザによる前記ゲームの実行において、他のユーザを出現させるステップと、
   前記他のユーザが前記第１のユーザと関係付けられていない第２のユーザである場合に、第１のユーザと第２のユーザを関係付ける操作、あるいは第１のユーザと第２のユーザの関係付けを申請する操作を受け入れるためのメニューを、前記ゲーム実行中のゲーム画像に表示させるステップと、
   前記操作に応じて、前記第１のユーザと前記第２のユーザを関係付けるステップと、
   を含む、ゲーム制御方法。
8. ゲームの実行を制御するために、コンピュータに、
   ユーザがゲームを実行する機能、
   第１のユーザによる前記ゲームの実行中において、記憶部から他のユーザを抽出して出現させる機能、
   前記他のユーザが前記第１のユーザと関係付けられていない第２のユーザである場合に、第１のユーザと第２のユーザを関係付ける操作、あるいは第１のユーザと第２のユーザの関係付けを申請する操作を受け入れるためのメニューを、前記ゲームの実行中のゲーム画像に表示させる機能、及び
   前記操作に応じて、前記第１のユーザと前記第２のユーザを関係付けて前記記憶部に記憶する機能、
   を実現させるためのプログラム。
9. 通信端末と、当該通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置と、を含むゲームシステムであって、
   ユーザ間を関係付ける関係付け手段、
   ユーザがゲームを実行する実行手段、
   第１のユーザによる前記ゲームの実行中において、他のユーザを出現させる出現手段、及び
   前記他のユーザが前記第１のユーザと関係付けられていない第２のユーザである場合に、第１のユーザと第２のユーザを関係付ける操作、あるいは第１のユーザと第２のユーザの関係付けを申請する操作を受け入れるためのメニューを、前記ゲームの実行中のゲーム画像に表示させる表示手段
   の各手段を、前記通信端末又は前記ゲーム制御装置のいずれか一方が備えた、
   ゲームシステム。

Images