JP2013172944A - ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム - 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）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図１０に、データベースサーバ３０の構成の一例を示す。図１０に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。

図１１に、上述したゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名／表示画像、体力ポイント、仲間のユーザＩＤ、保有カードの画像データ、及び保有カードのパラメータの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０にユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・体力ポイント
上記ゲームにおいて、ユーザによるゲームを進行させる上で必要となるポイントである。体力ポイントは、探索を行うことで低減し、所定の時間が経過する毎に回復（増加）する値である。
・仲間のユーザＩＤ
対象となるユーザＩＤと関係付けられた他のユーザＩＤのデータである。
・保有カードの画像データ
上記ゲームの場合、保有カードの画像データは、ユーザが保有する戦士カードについての画像を含むデータである。
・保有カードのパラメータ
保有カードのパラメータは、戦士カードの能力値を示すデータである。例えば、図１１に示すように、パラメータの項目として「攻撃力」，「防御力」の各々の各能力値が含まれてもよい。

ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、マップ１０１の探索状況を示す情報、攻略済み、及び攻略中のマップの情報などを含む。

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

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

登録手段５１はまた、ユーザＩＤに基づく申請を契機として当該ユーザＩＤを他のユーザＩＤとを関係付けて登録してもよい。すなわち、登録手段５１は、ユーザＩＤに基づく申請を契機として、他のユーザＩＤ（つまり、他のユーザ）を「仲間」として登録する。
この場合の登録手段５１は例えば、以下のとおり実行される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されている。ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示させるＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間」の箇所（図１１参照）にデータを書き込む。
なお、登録手段５１は、上述した申請及び承認の手順を採らずに、仲間を登録してもよい。例えば、ＣＰＵ２１は、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（申請）を受け付けることで、指定先のユーザＩＤのユーザの承諾を得ることなく指定先のユーザＩＤを仲間として登録してもよい。
なお、ユーザ同士を関係付ける条件は、上述したものに限られず、同一のゲーム上のステージ若しくはエリアを実行するユーザや試合を行ったユーザ同士を仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間で対戦（バトル）を行うゲーム上のモードが存在する場合には、所定回数以上対戦を行ったユーザ同士や、協力して敵キャラクタと対戦をしたユーザ同士を自動的に仲間として登録してもよい。
本実施形態では、ユーザ同士の仲間関係の登録をユーザデータベース３１にデータを書き込むことによって実現する例を示したが、この例に限られない。仲間関係に関するデータは、ゲームサーバ２０からアクセス可能なネットワーク上の外部の記憶装置に書き込まれるようにしてもよい。

ゲーム進行手段５２は、通信端末１０に対するユーザの操作に応じて、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータを送信することで、本実施形態のゲームを進行させる機能を備える。ゲーム進行手段５２によって行われる処理としては、例えば、以下の探索処理とバトル処理を含む。

［探索処理］
ゲーム進行手段５２は、マップ１０１上のいずれかのプレイエリア（領域）に隠れたスパイキャラクタを探索する探索処理を実行する機能を備える。ゲーム進行手段５２における探索処理の実現方法について、以下で説明する。

ユーザの通信端末１０に表示される図６（ａ）に示したウェブページでは、マップ１０１内のいずれかのプレイエリアを選択する操作を受け入れるように構成されている。図６（ａ）では、ユーザによって選択されたプレイエリアをユーザ位置ＵＡと表記している。ＣＰＵ２１は、ユーザによって選択されたユーザ位置ＵＡを認識すると、図６（ｂ）に示したウェブページを表示するためのＨＴＭＬデータを通信端末１０宛に送信する。図６（ｂ）に示したウェブページは、探索ゲージ１０２と、体力ポイントを示すテキスト１０３と、「探索する」というテキストが表記されたメニューｍ１０とを含む。ここで、メニューｍ１０が選択操作されたことをＣＰＵ２１が認識すると、その都度、探索ゲージ１０２の値（％）がランダムな増加量にて増加して表示され、体力ポイントを示す数字が一定量低下する。探索ゲージ１０２の値（％）が１００％になると、そのプレイエリアの探索が完了したことになる。
ＣＰＵ２１は、マップ１０１上のいずれかのプレイエリアにスパイキャラクタを設定（配置）する。ＣＰＵ２１は、ユーザによって選択されたプレイエリアと、スパイキャラクタを設定したプレイエリアとが一致したと判断した場合には、そのプレイエリアの探索における探索ゲージ１０２の値（％）が１００％になったとき、あるいは１００％になる前の任意のタイミングで、バトル処理の実行を開始する。つまり、ＣＰＵ２１は、図８（ａ）及び（ｂ）に示すウェブページを表示するＨＴＭＬデータを通信端末１０宛に送信する。

［バトル処理］
ゲーム進行手段５２は、戦士カードを使用したユーザとスパイキャラクタとの間のゲーム上のバトルを実行する機能を備える。
手持ちの戦士カードを使用したスパイキャラクタとのバトルは、以下のように設定されてもよい。例えば、ユーザが保有する戦士カードの中からスパイキャラクタとのバトルに参加する戦士カードを予め選択しておく。あるいは、ＣＰＵ２１が、対象となるユーザＩＤのユーザデータに含まれる複数の戦士カードの中からランダムに選択してもよい。
図８（ｂ）に示すウェブページ上でメニューｍ１１が選択操作されたことを認識すると、ゲームサーバ２０のＣＰＵ２１は、バトル処理を開始する。バトル処理は任意の方法で行うことができるが、例えば以下の方法を採ることができる。スパイキャラクタには、体力を示す値（ＨＰ）が設定されており、バトル中のスパイキャラクタのＨＰが図８（ｂ）のＨＰゲージ１０４で表示される。ユーザは、１又は複数の戦士カードによる攻撃を行うことでスパイキャラクタのＨＰを低下させる。ＣＰＵ２１は、図８（ｂ）のメニューｍ１１の選択操作によってユーザによる攻撃指示を認識して、スパイキャラクタのＨＰを低下させる。スパイキャラクタのＨＰの低下量は、バトルに参加する戦士カードの攻撃力のパラメータに応じたものとすることが好ましいが、ランダムに変化させてもよい。

ＣＰＵ２１は、例えば、メニューｍ１１に対する所定回数の操作によってバトル結果を決定する。例えば、ＣＰＵ２１は、メニューｍ１１に対する所定回数の操作によってスパイキャラクタのＨＰがゼロにならない場合には、スパイキャラクタを倒すことができず、スパイキャラクタが他のプレイエリアに逃走する（つまり、スパイキャラクタを再配置する）ゲーム設定とする。つまり、ユーザの通信端末１０宛に、図７に示すウェブページを表示するためのＨＴＭＬデータを送信するとともに、既に探索済みのプレイエリア以外のプレイエリア（図７の例では、プレイエリア４−２（マーク１０１ａが表示されているプレイエリア）以外のいずれかのプレイエリア）に設定（配置）する。一方、メニューｍ１１に対する所定回数以内の操作によってスパイキャラクタのＨＰがゼロになった場合には、スパイキャラクタを倒し、マップ１０１を攻略したものとするゲーム設定とする。この場合、ユーザの通信端末１０宛にスパイキャラクタを倒したことを通知するＨＴＭＬデータを生成して送信する。

アクセス情報取得手段５３は、ゲームサーバ２０に登録済みのユーザによる通信端末１０からのアクセスに関する情報を取得する機能を備える。
なお、「アクセス」には、パスワードや個体識別番号等、認証に必要な情報を通信端末１０から送信してアクセスする場合（ログインの場合）や、ログイン後にゲーム上の操作入力に関する情報を送信してウェブページの更新を要求する場合（例えばＨＴＴＰリクエストを送信する場合）などが含まれる。

アクセス情報取得手段５３の機能は以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、ユーザＩＤに基づくアクセスがある度に、そのアクセスに関する情報をゲームデータベース３２内のログデータに記録する。図１３にログデータの構成例を示す。図１３に示すように、ログデータは、ユーザＩＤ、アクセス対象のプレイエリア、アクセスの時刻の情報が、アクセスがあった時刻の順に記述されたデータである。
上述した探索処理において、図６（ａ）に示したウェブページのマップ１０１内のいずれかのプレイエリアに対するユーザの選択操作があったことを認識した時点において、ＣＰＵ２１は、ログデータ内でユーザＩＤと関連付けて、特定のプレイエリアと、そのプレイエリアに対するアクセスの時刻を記録する。なお、図１３において、プレイエリアの欄に何も記述されていないアクセスは、ログインによるアクセスであることを示している。

算出手段５４は、プレイ中のユーザ（第１のユーザ）と仲間の関係にあって、かつ所定期間内にアクセスしているユーザ数を算出する機能を備える。ここで、所定期間の起算点については２通りの方法を採ることができる。１つの方法は、プレイ中のユーザがログインした時刻を基準として、その時刻（基準時刻という。）の所定時間内にアクセスしている仲間のユーザの数を算出する方法である。もう１つの方法は、プレイ中のユーザがゲーム上の操作入力が行ってアクセスが行われた時刻を基準にして、その時刻（基準時刻という。）の所定時間内にアクセスしている仲間のユーザの数を算出する方法である。後者の方法はアクセスする度にユーザ数を算出することになるためＣＰＵ２１の負荷が掛かるが、算出されるユーザ数の精度が高くなる。つまり、ユーザは、ログインしてから集中的にアクセスを行うとは限らないため、ログインの時刻を基準とするよりもユーザ数の算出精度が高くなる。

算出手段５４の機能は、以下の通り実現することができる。ゲームサーバ２０のＣＰＵ２１は、ゲームデータベース３２にアクセスしてログデータを参照して、対象となるユーザのログイン時刻を基準として所定時間内にアクセスしている仲間のユーザ数を算出する。あるいは、ＣＰＵ２１は、対象となるユーザからアクセスがある度に、ゲームデータベース３２にアクセスしてログデータを参照して、対象となるユーザからアクセスしている時刻を基準として所定時間内にアクセスしている仲間のユーザ数を算出する。なお、ＣＰＵ２１は、仲間のユーザを判別するために対象となるユーザのユーザデータを参照する。

情報量調整手段５５は、算出手段５４によって算出されたユーザ数の値が大きいほど、プレイ中のユーザに提供するゲーム上の情報の量を多くする機能を備える。本実施形態において、可視化エリアは「ゲーム上の情報の量」の一例である。
ここで、上述したゲームの内容に関連して情報量調整手段５５の情報量の調整内容について説明する。図５〜８に関連して説明した本実施形態のゲームによれば、マップ１０１のいずれかのユーザ位置ＵＡをユーザが選択して探索処理を行った後、スパイキャラクタが見つからなかった場合、以下の処理が行われる。つまり、ユーザ位置ＵＡを基準として、算出手段５４によって算出されたユーザ数の値に応じた１又は複数のプレイエリアの範囲である可視化エリア内にスパイキャラクタが隠れている（配置されている）場合、スパイキャラクタが隠れているプレイエリアがユーザに視認できるようなウェブページが表示される。例えば、ユーザ位置ＵＡ（図６（ａ）では、プレイエリア４−２）をユーザが選択して探索処理を行った後、スパイキャラクタが見つからなかった場合のウェブページの表示例を図１４（ａ）及び（ｂ）に示す。図１４（ａ）は、算出手段５４によって算出されたユーザ数の値が比較的少ない場合の可視化エリアの一例を示したものであり、図１４（ｂ）は、算出手段５４によって算出されたユーザ数の値が比較的多い場合の可視化エリアの一例を示したものである。この例では、スパイキャラクタがプレイエリア４−４に隠れている場合が想定されており、図１４（ａ）の可視化エリア内にはスパイキャラクタを視認できないが、より広い図１４（ｂ）の可視化エリア内にはスパイキャラクタを視認できるようになっている。よって、図１４（ｂ）の可視化エリアを見たユーザは、次のプレイエリアの選択時にはプレイエリア４−４を選択することで、スパイキャラクタを見つけ出しスパイキャラクタとのバトルを実行することができる。
なお、図１４は、ユーザがいずれかのプレイエリアを選択操作した時点で表示されるように設定してもよい。つまり、探索処理を経ずして可視化エリアを表示するようにしてもよい。

情報量調整手段５５の機能は、以下のように実現することができる。例えばゲームサーバ２０のＲＡＭ２３には、基準時刻を基準として所定時間内にアクセスしている仲間の数と、マップ１０１上のユーザ位置ＵＡ（ユーザによって選択されたプレイエリア）を基準とした可視化エリアの範囲とが対応付けられたデータが記憶されている。図１５は、そのデータの一例であり、ユーザ位置ＵＡをマップ１０１の中心であるプレイエリア３−３とした場合の、所定時間内にアクセスしているユーザ数に応じた可視化エリアの範囲を示している。ＣＰＵ２１は、図１５に示したデータを参照して、ユーザが実際に選択して探索処理を行ったユーザ位置ＵＡを基準とした可視化エリアを特定し、その可視化エリアを含むウェブページを表示するためのＨＴＭＬデータを生成する。特定された可視化エリア内のいずれかのプレイエリアにスパイキャラクタが配置されている場合には、マップ１０１のいずれかのプレイエリアにスパイキャラクタが表示される。
なお、ユーザ数に応じた可視化エリアの範囲の設定は、図１５に示した形式に限られず、所定の計算式によって算出してもよい。例えば、算出されたユーザ数に所定の定数を乗算して可視化エリアの所定形状（矩形等）の面積や、円形の可視化エリアの半径等を算出するようにしてもよい。
可視化エリアの範囲の設定は、ユーザ位置ＵＡを基準とした、算出されたユーザ数に応じた大きさとする場合に限られない。可視化エリアの範囲の設定を、基準時刻を基準として所定時間内にアクセスしている仲間がアクセスしているエリアに基づいて決定してもよい。その場合、ＣＰＵ２１は、ログデータ（図１３）を参照して、プレイ中のユーザ（第１のユーザ）の仲間であって、所定期間内にアクセスしたユーザの数を、アクセスしたエリアごとに算出する。そしてＣＰＵ２１は、仲間がアクセスした数が多いエリアであるほど、そのエリアを基準とした可視化エリアが広くなるようにして、可視化エリアの範囲を決定する。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置がゲームを実行する場合において、上述した可視化エリアを含むＨＴＭＬデータを生成・送信するときの処理の一例について、図１６のフローチャートを参照して説明する。図１６は、フローチャートは主としてゲーム進行手段５２、算出手段５４及び情報量調整手段５５によって実行される。

先ず、ユーザ（第１のユーザ）の通信端末１０に表示されるゲームの初期画面では、図６（ａ）に示すように、所定個数のプレイエリアからなるマップ１０１が表示される。このゲームでは、マップ１０１内において、ゲームサーバ２０によって予め定められたいずれかのプレイエリアにスパイキャラクタが隠れている設定となっている。先ず、マップ１０１上でいずれかのプレイエリアが選択操作されると（ステップＳ１０：ＹＥＳ）、探索を実行するための図６（ｂ）のウェブページに更新される。図６（ｂ）のウェブページでは、ユーザによるメニューｍ１０を選択操作に応じて、ゲームサーバ２０は、ユーザの体力ポイントを一定量消費しつつ探索処理を実行する（ステップＳ１２）。メニューｍ１０を選択操作する度に探索ゲージが進行して１００％に到達すると探索が終了となる。ここで、ゲームサーバ２０は、スパイキャラクタが設定されたプレイエリアと、ユーザによって選択されたプレイエリアとが一致した場合に、スパイキャラクタが見つかったと判断し（ステップＳ１４：ＹＥＳ）、戦士カードを使用したスパイキャラクタとの間のバトル処理を実行する（ステップＳ１６）。このとき、図８（ａ）及び（ｂ）に示すウェブページが順に表示するためのＨＴＭＬデータをユーザの通信端末１０宛に送信する。ユーザによるメニューｍ１１の選択操作の結果、戦士カードを使用してユーザがスパイキャラクタとのバトルに勝利した場合（ステップＳ１８：ＹＥＳ）、マップ１０１が攻略されたことになり、次のマップへ進む。ユーザがスパイキャラクタとのバトルに勝利できなかった場合（ステップＳ１８：ＮＯ）、ゲームサーバ２０は、ステップＳ１０で選択されたプレイエリア以外のいずれかのプレイエリアにスパイキャラクタを再度設定（つまり、再配置）する（ステップＳ２０）。つまり、スパイキャラクタは新たなプレイエリアに逃げ込むゲーム設定となっている。

ステップＳ１４でスパイキャラクタが見つからなかった場合、あるいは、ステップＳ１８でスパイキャラクタとのバトルに勝利できなかった場合には、ゲームサーバ２０は、可視化エリアを表示する処理であるステップＳ２２〜Ｓ２６の処理を行う。
つまり、ゲームサーバ２０は、ログデータを参照して、対象となるユーザの仲間のユーザのうち所定時間内にアクセスしているユーザ数（Ｎ）を算出する（ステップＳ２２）。次にゲームサーバ２０は、図１５に示したデータを参照し、ステップＳ１０で選択されたプレイエリア（ユーザ位置ＵＡ）を基準としてステップＳ２０で算出されたユーザ数（Ｎ）に応じた可視化エリアを決定する（ステップＳ２４）。次いで、ゲームサーバ２０は、可視化エリアを含むウェブページを表示するためのＨＴＭＬデータを生成して、対象となるユーザの通信端末１０宛に送信する（ステップＳ２６）。ここで、ゲームサーバ２０は、可視化エリア内のいずれかのプレイエリアにスパイキャラクタが隠れている（配置されている）場合には、ユーザは、スパイキャラクタの位置を視認（特定）することができるようにＨＴＭＬデータを生成する。その後、可視化エリアを表示するウェブページ上での適切な選択操作に応じて、例えば図６（ａ）に例示したように、マップ１０１上でいずれかのプレイエリアをユーザが選択するためのウェブページに更新される。

以上説明したように、本実施形態のゲームシステムによれば、プレイ中のユーザと仲間の関係にあるユーザうち所定時間内にゲームサーバにアクセスしているユーザ数の値が大きいほど、プレイ中のユーザに提供されるウェブページ上では、より広範囲な可視化エリアが表示されるため、スパイキャラクタを見つけ出すことができる可能性が高くなり、ゲームを有利に進めることができるようになる。つまり、プレイ（実行）中のユーザには、所定時間内にアクセスしている仲間のユーザの数が多いほど、多くのゲーム上の情報が与えられることになるため、ユーザは、仲間と同時にログインすることが動機付けられる。これによって、同時にプレイしている仲間同士で助け合いながら、あるいはコミュニケーションをとりながらゲームを進めることになるため、仲間間の連携を図った興趣性の高いゲームを実現でき、ソーシャル性を高めることができる。

（８）変形例
（８−１）変形例１
上述した実施形態において、情報量調整手段５５は、アクセスしている仲間のユーザの数に応じて提供される情報は、視覚化エリアの情報に限られず、テキスト情報あるいは音声情報であってもよい。図１７に、ユーザに対して提供される情報がテキスト情報である場合の例を示す。図１８に、ユーザに対して提供される情報が音声情報である場合の例を示す。図１７及び図１８において、（ａ）はアクセスしている仲間のユーザの数が比較的少ない場合を、（ｂ）はアクセスしている仲間のユーザの数が比較的多い場合をそれぞれ例示している。

図１７では、図１４に示した視覚化エリアの情報に代えて、ユーザに提供されるウェブページ上の表示領域２０１にテキスト情報が提供される。図１７（ａ）では、「スパイは東の方にいる！」というテキストが表示され、このテキストはユーザがいずれかのプレイエリアを選択するときのヒントとなる。これに対し、図１７（ｂ）では、「スパイは東の飲食店にいる！」というテキストが表示され、図１７（ａ）の場合よりも多くのヒントが与えられる。
図１８では、図１４に示した視覚化エリアの情報に代えて、ユーザに提供されるウェブページ上に、例えば「仲間のヒントを聞く」と表記されたメニューｍ２０が設けられる。図１８（ａ）では、メニューｍ２０の選択操作に応じて「スパイは東の方にいる！」という音声が出力され、この音声はユーザがいずれかのプレイエリアを選択するときのヒントとなる。これに対し、図１８（ｂ）では、メニューｍ２０の選択操作に応じて「スパイは東の飲食店にいる！」という音声が出力され、図１８（ａ）の場合よりも多くのヒントが与えられる。

本変形例の場合には、図１５に示したデータの代わりに、アクセスしている仲間のユーザ数と、ユーザ位置ＵＡを基準としたスパイキャラクタの隠れているプレイエリアの方角及び／又は建物の種別とが対応けられたデータが設けられてもよい。例えば、そのデータには、アクセスしている仲間のユーザの数が少ない場合には、スパイキャラクタの隠れているプレイエリアの方角、又は建物の種別が記述され、アクセスしている仲間のユーザの数が多い場合には、スパイキャラクタの隠れているプレイエリアの方角、及び建物の種別が記述される。ゲームサーバ２０のＣＰＵ２１は、ユーザ位置ＵＡと、スパイキャラクタが位置するプレイエリアとに基づいて、図１７の表示領域２０１に表示すべきテキストを生成し、当該テキストを含むＨＴＭＬデータに通信端末１０宛に送信する。
ユーザの通信端末１０宛に音声情報を送信する場合には、ゲームサーバ２０のＣＰＵ２１は、生成したテキストを音声合成処理して生成した音声情報をＨＴＭＬデータとともに通信端末１０宛に送信する。なお、通信端末１０に音声合成ソフトウエアが内蔵されている場合には、ゲームサーバ２０はテキスト情報のみを通信端末１０宛に送信してもよい。

（８−２）変形例２
上述した実施形態では、所定のマップを攻略するゲームを例にして説明した。これに対し、ゲームが複数のパート（部分）から構成されている場合を想定する。このようなゲームにおいて、各パートがそれぞれ独立したミニゲームであってもよいし、各パートが相互に関連していてもよい。また、所定のマップを攻略する複数のステージ（パート）からゲームが構成されていることもある。このような複数のパートからなるゲームでは、算出手段５４は、算出の対象となるユーザと同一のパートにアクセスしている（つまり、同一のパートをプレイしている）ユーザ数を算出することが好ましい。これにより、ユーザは、ゲーム上でより多くの情報を得るために仲間と同時にログインして互いに同一のパートを実行することが動機付けられる。これによって、同時にプレイしている仲間同士で同一のパートを助け合いながらゲームを進めることができる。

そこで、本変形例では、ゲームが複数のパートから構成されている場合、算出手段５４は、特定のパートを実行中のユーザ（第１のユーザ）と関係付けられ、かつ第１のユーザと同一のパートを実行するユーザ数を算出する機能を備えてもよい。この場合の算出手段５４の機能は、以下の通り実現することができる。ログデータは、図１３に示したものに加えて、各ユーザがアクセスするゲーム内のパートも記録するようにする。そして、ゲームサーバ２０のＣＰＵ２１は、ゲームデータベース３２にアクセスしてログデータを参照して、対象となるユーザのログイン時刻を基準として所定時間内にアクセスしている仲間のユーザのうち、対象となるユーザと同一のパートを実行しているユーザ数を算出する。あるいは、ＣＰＵ２１は、対象となるユーザからアクセスがある度に、ゲームデータベース３２にアクセスしてログデータを参照して、対象となるユーザからアクセスしている時刻を基準として所定時間内にアクセスしている仲間のうち、対象となるユーザと同一のパートを実行しているユーザ数を算出する。
上述した実施形態において、「パート」はマップ単位でもよいし、プレイエリア単位でもよい。例えば、算出手段５４は、算出の対象となるユーザと同一のプレイエリアにアクセスしている（つまり、同一のプレイエリアを実行している）ユーザ数を算出してもよい。この場合、仲間のユーザと同時にログインして、共通のプレイエリアを中心とした可視化エリアを広げたいという動機付けをユーザに付与できる。

なお、ゲームが複数のパートから構成されている場合、算出手段５４は、特定のパートを実行中のユーザ（第１のユーザ）と関係付けられ、かつ第１のユーザが実行中のパートを基準に所定の範囲内のパート（つまり、第１のユーザが実行中のパートに近いパート）を実行するユーザ数を算出する機能を備えてもよい。つまり、仲間同士が実行するパートは必ずしも同一でなくてもよい。その場合、第１のユーザが実行中のパートを基準として「所定の範囲内のパート」は、適宜設定してよい。例えば、ゲームが複数のステージから構成されている場合、ステージの差が所定値以下である場合に、実行中のパートが「所定の範囲内のパート」であると判断してもよい。例えば、ゲームが第１ステージから第１０ステージで構成されている場合に、第１のユーザが第３ステージを実行中であってその仲間が第４ステージを実行しているときには、「所定の範囲内のパート」と判断してもよい(この場合、所定の範囲は１ステージ分）。また、第１のユーザが実行中のステージと同一のステージをその仲間が実行中であって、そのステージ上のプレイ中の位置が近い場合（例えば、各ユーザが操作しているゲームキャラクタ同士が同一のステージ上のエリア内で近い位置にいる場合）に、「所定の範囲内のパート」と判断してもよい。このような場合、情報量調整手段５５は、第１のユーザと実行中のパートを基準として所定の範囲内のパートを実行するユーザの数が多いほど、第１のユーザに提供するゲーム上の情報の量を多くしてもよい。
以上の構成によって、仲間同士が同一又は近いパートを協同でプレイすることが動機付けられる。

（８−３）変形例３
本変形例では、ゲームへのアクセスに関する情報は、ユーザのゲームへのアクセス時の当該ユーザの操作内容を含む。
算出手段５４は、プレイ中のユーザ（第１のユーザ）と仲間の関係にあって、かつ所定期間内にアクセスしているユーザの中から、第１のユーザと上記所定期間内でのアクセス時の操作内容が同一であるユーザの数を算出する。
ユーザ間での同一の操作内容は、上述した実施形態の場合には、例えば、同一のエリアを選択する操作であってもよいが、それに限られない。操作内容は適用されるゲームの内容やシナリオに応じて任意に設定してもよく、例えば、同一の移動方向を指示する操作内容であってもよいし、同一のゲームキャラクタ（例えば、同一のボスキャラクタ）とのバトルを行うための操作内容であってもよい。
この構成では、第１のユーザと所定期間内でのアクセス時の操作内容が同一であるユーザの数を基礎として第１のユーザに提供される情報の量が決定される。そのため、ゲームにおいて同一の場面、同一の状況にある仲間のユーザ数が、得られる情報の量に反映されることになり、仲間のユーザと協力して同時にゲームを行っている感覚を得ることができる。
本変形例は、例えば以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、ユーザＩＤに基づくアクセスがある度に、そのアクセスに関する情報をゲームデータベース３２内のログデータに記録する。図１９に本変形例のログデータの構成例を示す。図１９に示すように、ログデータは、ユーザＩＤごとに、アクセス時刻とユーザの操作内容の情報とが、アクセス時刻の順に記述されたデータである。ＣＰＵ２１は、第１のユーザによる操作入力に基づくアクセスが生じた場合には、所定期間内に第１のユーザと同一の操作入力に基づくアクセスを行った仲間のユーザの数を、ログデータを参照して取得する。そしてＣＰＵ２１は、図１５のデータを参照し、取得した仲間の数に基づいて、ゲーム上の情報の量としての可視化エリアの範囲を決定する。

（８−４）変形例４
上述した実施形態において、算出手段５４は、ユーザがゲームにログインした時刻、あるいはプレイ中のユーザがゲーム上の操作入力を行ってアクセスが行われた時刻を基準として、所定期間内にアクセスしている仲間のユーザ数を算出する場合について説明したが、この場合に限られない。算出手段５４は、アクセス情報取得手段５３が取得したアクセスに関する情報に基づいて、プレイ中のユーザ（第１のユーザ）と仲間の関係にあって、かつゲームにアクセスしているユーザの数を定期的に算出し、第１のユーザがゲームにアクセスした時点、又は第１のユーザがゲーム上の操作入力によってアクセスした時点における直近の上記数を、算出対象のユーザ数としてもよい。このようにすることで、ユーザ数の算出が定期的に行われ、各ユーザによる任意のアクセスの都度にユーザ数の算出を行わずに済むため、処理の負荷が分散されることになる。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、定期的にゲームデータベース３２にアクセスしてログデータを参照し、ゲームにアクセスしている仲間のユーザ数を算出して記録する。そしてＣＰＵ２１は、対象となるユーザのログイン、又は対象となるユーザからの操作入力によるアクセスが生ずると、直近に記録したユーザ数を読み出す処理を行う。

（８−５）変形例５
本変形例のゲーム制御装置の機能ブロック図を図２０に示す。図２０に示す機能ブロック図は、図１２に示したものと比較して、親密度設定手段５６が追加された点で異なる。
親密度設定手段５６は、登録手段５１によって関係付けられたユーザ間の親密度を設定する機能を備える。
本変形例では、算出手段５４は、プレイ中のユーザ（第１のユーザ）と仲間の関係にあって、かつ所定期間内にアクセスしているユーザの中から、第１のユーザとの間に設定された親密度の値が所定値以上であるユーザの数を算出する機能を備える。
この構成では、親密度が高い仲間のユーザの数に応じて提供されるゲーム上の情報の量が決定される。つまり、他のユーザとの親密度が高いユーザがゲームにおいて有利となることから、ユーザ間で関係性を高めるように動機付けられる。

本変形例は、以下のようにして実現することができる。
先ず親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものである。親密度のデータ（親密度データ）の一例を図２１に示す。図２１に示す親密度データの例では、各ユーザの仲間のユーザ（ユーザＩＤ）と対応付けて、ユーザ間の応援メッセージの送信あるいは受信の頻度（応援頻度）、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数（プレゼント回数）などが記録され、これらの頻度や回数に基づいて一定の基準で親密度の値が設定される。応援頻度やプレゼント回数が多いほど親密度が高く設定される。また、一定の基準では、親密度の設定の基礎となる項目（図２１では、応援頻度やプレゼント回数など）ごとに、重み付けを考慮したものであってもよい。例えば、応援頻度が少なくてもプレゼント回数が多い場合に親密度を高く設定してもよい。このような親密度データは、例えば、ユーザデータベース３１内に記録される。つまり、ゲームサーバ２０のＣＰＵ２１は、ユーザ間での上記メッセージやアイテム等の送受信の回数や頻度のデータ、及びこれらのデータに基づく親密度の値を、親密度データに書き込む。
ＣＰＵ２１は、親密度データを参照して、プレイ中のユーザ（第１のユーザ）と仲間の関係にあって、かつ所定期間内にアクセスしているユーザのうち、親密度の値が所定値以上の仲間の数を算出する。次いでＣＰＵ２１は、図１５のデータを参照し、算出した仲間の数に基づいて、ゲーム上の情報の量としての可視化エリアの範囲を決定する。

（８−５）変形例６
本変形例では、変形例５に係るゲーム制御装置の親密度設定手段５６は、登録手段５１によって関係付けられたユーザ同士が同一の期間内でゲームにアクセスした回数、又は頻度に基づいて親密度を設定する。
この構成では、仲間のユーザ同士が同一の期間内で一緒にゲームをより頻繁に行うほど、ゲーム上の情報の量が多く得られ、ゲームを有利に進行させることができるため、特定のユーザ同士で同一の期間内で一緒にゲームを行うように、互いにコミュニケーションをとることが期待できる。つまり、ゲームのソーシャル性を高めることができる。
本変形例は、以下のようにして実現することができる。本変形例の親密度は、図２０に示したものと異なり、同一の期間内でゲームにアクセスした回数、又は頻度に基づいて決定される。ゲームサーバ２０のＣＰＵ２１は、例えば定期的に（１５分毎等）ログデータ（図１３）を参照し、アクセス時刻の差が所定時間以内である仲間同士を同一の期間にアクセスしたと判断して、記録する。ＣＰＵ２１は、記録したデータを基に、同一の期間内でゲームにアクセスした回数が多いほど、又は頻度が高いほど親密度が高くなるようにして、親密度を決定する。ＣＰＵ２１は、親密度の値に基づいて、プレイ中のユーザ（第１のユーザ）と仲間の関係にあって、かつ所定期間内にアクセスしているユーザのうち、親密度の値が所定値以上の仲間の数を算出する。次いでＣＰＵ２１は、図１５のデータを参照し、算出した仲間の数に基づいて、ゲーム上の情報の量としての可視化エリアの範囲を決定する。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、上記実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。上述した実施形態及び各変形例で述べた特徴は、矛盾が生じない限り適宜組合せもよい。

上述した実施形態のゲームでは、ユーザによっていずれかのプレイエリア（領域）に対する操作入力が行われ（つまり、ユーザによって選択操作され）、アクセスに関する情報には、その操作入力結果が含まれるが、このような場合に限られない。ユーザのいずれかの領域への関連付けがユーザの操作入力を契機としないようなゲームも想定しうる。例えば、ユーザの所在地を示す位置情報、例えば、ＧＰＳ(Global Positioning System)信号が通信端末１０からゲームサーバ２０宛にログイン又はアクセス時に自動的に通知される設定となっている場合、そのＧＰＳ信号に基づくユーザの所在地に応じて、マップのいずれかのプレイエリアにゲーム上でユーザが関連付けられる場合であってもよい。

上述した実施形態において、算出手段５４は、ゲームを実行中のユーザと仲間であって、かつ所定期間内に所定回数以上アクセスしているユーザの数を算出してもよい。これにより、積極的にゲームを実行するユーザの数を算出することで、そのようなユーザとの間で助け合いながらゲームを進めることになるため、積極的にプレイするユーザとのコミュニケーションを促進させることができる。この場合、ＣＰＵ２１は、図１３に示したログデータに基づいて、所定期間内のユーザＩＤごとのアクセスの回数をカウントして上記ユーザの数を算出する。

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

上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、図１２に示した各手段の機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。その場合、上述した実施形態において、各ユーザの通信端末１０は、アクセスに関する情報をゲームサーバ２０から逐次受信して取得し、あるいはユーザ数の算出結果を逐次ゲームサーバ２０から受信して取得して記憶装置（ＲＡＭ１３、あるいは図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置等）に記憶させるようにしてもよい。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…無線通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…ゲーム進行手段
５３…アクセス情報取得手段
５４…算出手段
５５…情報量調整手段

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

（８）変形例
（８−１）変形例１
上述した実施形態において、情報量調整手段５５は、アクセスしている仲間のユーザの数に応じて提供される情報は、可視化エリアの情報に限られず、テキスト情報あるいは音声情報であってもよい。図１７に、ユーザに対して提供される情報がテキスト情報である場合の例を示す。図１８に、ユーザに対して提供される情報が音声情報である場合の例を示す。図１７及び図１８において、（ａ）はアクセスしている仲間のユーザの数が比較的少ない場合を、（ｂ）はアクセスしている仲間のユーザの数が比較的多い場合をそれぞれ例示している。

図１７では、図１４に示した可視化エリアの情報に代えて、ユーザに提供されるウェブページ上の表示領域２０１にテキスト情報が提供される。図１７（ａ）では、「スパイは東の方にいる！」というテキストが表示され、このテキストはユーザがいずれかのプレイエリアを選択するときのヒントとなる。これに対し、図１７（ｂ）では、「スパイは東の飲食店にいる！」というテキストが表示され、図１７（ａ）の場合よりも多くのヒントが与えられる。
図１８では、図１４に示した可視化エリアの情報に代えて、ユーザに提供されるウェブページ上に、例えば「仲間のヒントを聞く」と表記されたメニューｍ２０が設けられる。図１８（ａ）では、メニューｍ２０の選択操作に応じて「スパイは東の方にいる！」という音声が出力され、この音声はユーザがいずれかのプレイエリアを選択するときのヒントとなる。これに対し、図１８（ｂ）では、メニューｍ２０の選択操作に応じて「スパイは東の飲食店にいる！」という音声が出力され、図１８（ａ）の場合よりも多くのヒントが与えられる。

Claims (13)

1. ユーザ同士を関係付けて登録する登録手段と、
   ユーザによるゲームへのアクセスに関する情報を取得する取得手段と、
   前記取得手段が取得したアクセスに関する情報に基づいて、ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしているユーザ数を算出する算出手段と、
   前記算出手段によって算出されたユーザ数の値が大きいほど、前記第１のユーザに提供するゲーム上の情報の量を多くする情報量調整手段と、
   を備えた、ゲーム制御装置。
2. 前記ゲームが複数のパートから構成されている場合、
   前記算出手段は、前記第１のユーザと関係付けられ、かつ前記第１のユーザと同一のパート、又は当該同一のパートを基準に所定の範囲内のパートを実行するユーザ数を算出し、
   前記情報量調整手段は、前記ユーザ数の値が大きいほど、前記第１のユーザに提供するゲーム上の情報の量を多くすることを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記ゲーム上の情報は、ゲーム画像上においてユーザが視認できる範囲の広さであることを特徴とする、
   請求項１又は２に記載されたゲーム制御装置。
4. 前記ゲーム上の情報は、テキスト情報又は音声情報であることを特徴とする、
   請求項１又は２に記載されたゲーム制御装置。
5. 前記算出手段は、前記第１のユーザによってゲーム上の操作入力が行われたことを認識した時点から前記ユーザ数を算出する、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. 前記ゲームへのアクセスに関する情報は、ユーザの前記ゲームへのアクセス時の当該ユーザの操作内容を含み、
   前記算出手段は、前記ユーザ数として、前記第１のユーザと前記所定期間内でのアクセス時の操作内容が同一であるユーザの数を算出することを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
7. 前記算出手段は、前記取得手段が取得したアクセスに関する情報に基づいて、前記第１のユーザと関係付けられ、かつ前記ゲームにアクセスしているユーザの数を定期的に算出し、前記第１のユーザが前記ゲームにアクセスした時点、又は前記第１のユーザが前記ゲーム上の操作入力によってアクセスした時点における直近の前記数を、前記ユーザ数とすることを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
8. 前記算出手段は、前記取得手段が取得したアクセスに関する情報に基づいて、前記第１のユーザと関係付けられ、かつ所定期間内に所定回数以上アクセスしているユーザ数を算出することを特徴とする、
   請求項１〜７のいずれかに記載されたゲーム制御装置。
9. 前記登録手段によって関係付けられたユーザ間の親密度を設定する親密度設定手段、を備え、
   前記算出手段は、前記ユーザ数として、前記第１のユーザとの間に設定された親密度の値が所定値以上であるユーザの数を算出することを特徴とする、
   請求項１〜８のいずれかに記載されたゲーム制御装置。
10. 前記親密度設定手段は、前記登録手段によって関係付けられたユーザ同士が同一の期間内で前記ゲームにアクセスした回数、又は頻度に基づいて前記親密度を設定することを特徴とする、
    請求項９に記載されたゲーム制御装置。
11. ユーザ同士を関係付けて登録するステップと、
    ユーザによるゲームへのアクセスに関する情報を取得するステップと、
    前記取得するステップで取得したアクセスに関する情報に基づいて、ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしているユーザ数を算出するステップと、
    前記算出するステップで算出されたユーザ数の値が大きいほど、前記第１のユーザに提供するゲーム上の情報の量を多くするステップと、
    を備えた、ゲーム制御方法。
12. コンピュータに、
    ユーザ同士を関係付けて登録する機能、
    ユーザによるゲームへのアクセスに関する情報を取得する機能、
    前記取得する機能によって取得されたアクセスに関する情報に基づいて、ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしているユーザ数を算出する機能、及び
    前記算出する機能によって算出されたユーザ数の値が大きいほど、前記第１のユーザに提供するゲーム上の情報の量を多くする機能、
    を実現させるためのプログラム。
13. ユーザによって操作される通信端末と、当該通信端末からのアクセスに応じて、前記通信端末によるゲームの実行を制御するサーバと、を含むゲームシステムであって、
    ユーザ同士を関係付けて登録する登録手段、
    ユーザによるゲームへのアクセスに関する情報を取得する取得手段、
    前記取得手段が取得したアクセスに関する情報に基づいて、ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしているユーザ数を算出する算出手段、及び、
    前記算出手段によって算出されたユーザ数の値が大きいほど、前記第１のユーザに提供するゲーム上の情報の量を多くする情報量調整手段、
    の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    ゲームシステム。

Images