JP2014087665A - ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、通信端末 - Google Patents

Abstract

【課題】ユーザが簡易な操作でゲームを行いつつ、ゲーム上の結果が得られるまでの過程に対して関心を持つことができるゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、通信端末を提供する。
【解決手段】現実世界の競技又は遊技を模擬したゲームを実行するゲーム制御装置であって、前記ゲーム上のイベントに先立って、前記競技又は遊技で実現可能な状況を設定する設定手段と、前記設定手段によって設定された状況の下で、所定の操作入力に関する情報に基づいて、前記イベントを発生させるイベント発生手段と、前記設定手段によって設定された状況と、前記イベント発生手段によって発生した前記イベントに基づき、前記ゲーム上の結果を発生させる結果発生手段と、を備える。
【選択図】図１３

Description

本発明は、ユーザによるゲームの実行を制御する技術に関する。

従来から、ユーザが自らゲーム装置を操作してゲームを楽しむことが行われている。この場合、ゲーム装置は、ゲーム用アプリケーションソフトウエア（ゲーム用アプリケーション）を読み込み、実行するためのハードウエアを備えている。このようなゲーム用アプリケーションにより実行されるゲームとして野球ゲーム等の対戦ゲームが知られている。このような対戦ゲームには、ゲームをより興趣に富むものとするために、対戦そのものはもとより、多彩なバリエーションが盛り込むようにすることが行われている。その一例は、ユーザの操作対象となるキャラクタの能力をユーザがカスタマイズできるような機能を含ませることなどである。 例えば、特許文献１には、キャラクタの行動スケジュールを作成するスケジュール作成手段を備え、キャラクタに特定の行動を指示すること等によりキャラクタの能力の増加などを図ることができるようにしたゲームシステム（野球ゲーム）が開示されている。このゲームシステムでは、キャラクタを育成し（つまり、キャラクタの能力を向上させて）、その後に他のユーザあるいはコンピュータとの間で対戦を行うこと、あるいは育成と対戦を交互に行うことが想定されている。

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

特開２０００−１８９６７７号公報

上述したソーシャルゲームは、ユーザにとって操作が簡易であり、例えば、野球等の現実世界の競技又は遊技を模擬したゲームであれば、対戦結果が直ちに確認できるようにしたものが多く、それ故、ゲームに長時間を掛けたくないユーザ、あるいは気軽にゲームを楽しみたいユーザに受け入れられている。しかしその一方で、ソーシャルゲームは、単なる釦の押下操作などで対戦結果が得られる場合がある。この場合、対戦結果が得られるまでの過程に対してユーザが関心を持たなくなるので、ゲーム性が単調になるという課題がある。

本発明は上述した観点に鑑みてなされたもので、ユーザが簡易な操作でゲームを行いつつ、ゲーム上の結果が得られるまでの過程に対して関心を持つことができるゲーム制御装置、ゲーム制御方法、プログラム、ゲーム制御システム、通信端末を提供することを目的とする。

本発明の第１の観点は、現実世界の競技又は遊技を模擬したゲームを実行するゲーム制御装置である。 当該ゲーム制御装置は、 現実世界の競技又は遊技を模擬したゲームを実行するゲーム制御装置であって、 前記ゲーム上のイベントに先立って、前記競技又は遊技で実現可能な状況を設定する設定手段と、 前記設定手段によって設定された状況の下で、所定の操作入力に関する情報に基づいて、前記イベントを発生させるイベント発生手段と、 前記設定手段によって設定された状況と、前記イベント発生手段によって発生した前記イベントに基づき、前記ゲーム上の結果を発生させる結果発生手段と、 を備える。

ここで、「イベント」とは、ゲームにおいて模擬された現実世界の競技又は遊技において起こり得る事象であれば任意に選択することができる。例えば、野球ゲームの場合には、イベントは、打撃のイベント、投球のイベントあるいは走塁のイベント等であってよい。例えば、サッカーゲームの場合には、イベントは、ペナルティーキックのイベントや、コーナーキックのイベント等であってもよい。また、「競技又は遊技で実現可能な状況」とは、例えば、野球ゲームの場合には、塁上にランナーが配置されている状況であってもよいし、打者に向かってボールが飛んでくる状況であってもよい。さらに、「所定の操作入力に関する情報」とは、例えば、ゲーム制御装置にアクセス可能な外部装置に対して所定の操作入力が行われたことを示す情報であってもよい。また、「ゲーム上の結果」とは、ゲーム全体の結果に限られず、ゲーム内の一部の局面における結果であってもよい。例えば、野球ゲームの場合には、打撃結果（例えばアウト又はヒット）であってもよいし、１回の打撃で獲得した得点であってもよい。

このゲーム制御装置では、設定された状況の下で、所定の操作入力に関する情報に基づいてイベントが発生すると、設定された状況とイベントとに基づきゲーム上の結果が得られる。これにより、ゲーム上の結果は、単に、操作入力に関する情報に基づいて決定されるのではなく、イベントに先立って設定された状況によっても影響を受けることになる。このため、ゲーム上の結果が得られるまでの過程に対してもユーザに関心を持たせることができる。したがって、従来のゲームの課題である、結果のみがわかればよいといった単調なゲーム性を解消することができ、ゲームの興趣性を高めることができる。 例えば、野球ゲームの場合、打者による打撃のイベントに先立ち設定される状況として、塁上にランナーが何人いるか、というケースをとり得る。この場合、ランナーが多いほど得点チャンスや得点数が増える可能性があるため、ユーザはこの設定状況に関心を持つことになり、ゲーム結果が出るまでの経過にも興味を持つことになる。

上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段と、ユーザからのアクセスに関する情報を取得する取得手段と、前記取得手段が取得したアクセスに関する情報に基づいて、前記ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしているユーザ数を算出する算出手段とを備え、前記設定手段は、前記ユーザ数の値が大きいほど、前記第１のユーザの前記ゲーム上の結果が有利になるように、前記状況を設定してもよい。 ここで、「アクセス」とは、例えば、通信端末から認証情報を送信してログインのためにアクセスする場合や、ログイン後にゲーム上の操作入力に関する情報を送信する場合等を含んでもよい。また、「所定期間内にアクセスしている」とは、例えば現在時刻等の基準時刻からみて過去の所定時間内に通信端末からアクセスが少なくとも１回行われたことを意味し、その所定期間内に必ずしも継続的な、あるいは連続的なアクセスが行われる必要はない。 このゲーム制御装置によれば、ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしているユーザ数の値が大きいほど、第１のユーザは、より有利なゲーム上の結果を得ることができる。このため、第１のユーザには、より有利なゲーム上の結果を得るために、関係付けられたユーザ（例えばユーザの仲間）と同時にアクセスすることが動機付けられる。すなわち、ゲームへのアクセスを多くすれば互いのメリットが向上することを仲間同士で認識しているため、ゲーム全体のアクセス数の向上に自然に寄与でき、この結果、ゲームのコミュニティの活性化、ソーシャル性を高めることができる。また、上記メリットを得るために、ユーザが仲間に対して、ゲーム内のチャットやメール、その他の手段でアクセスを呼びかけることも想定されるので、よりゲームのコミュニティの活性化を図ることができる。

また、上記ゲーム制御装置において、前記設定手段は、前記イベントが２回以上連続して発生する場合には、２回目以降の前記イベントに先立って前記状況を設定するときに、前記ユーザ数に代えて、前記ユーザ数からイベント毎に値を減らしたユーザ数に基づいて、前記状況を設定してもよい。 例えば、イベントが繰り返し行われる毎に、同じユーザ数（例えば、ユーザの仲間の数）に基づいて状況が設定される場合には、ユーザ数の値が大きければ、ゲーム上の有利な結果を得ることの可能な状況が常に設定されることから、仲間の数が多いユーザが突出して有利になってしまい、全体的なゲームのバランスが偏ってしまう可能性がある。一方、このゲーム制御装置によれば、イベントの経過に従って、ユーザ数（ユーザの仲間の数）を低減させていき、この低減された数に基づいて、状況の設定が行われるので、上記のようなバランスの偏りを抑制することができる。

上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段と、ユーザからのアクセスに関する情報を取得する取得手段とを備え、前記設定手段は、前記取得手段が取得したアクセスに関する情報に基づいて、前記ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしている第２のユーザが抽出された場合に、前記第１のユーザと前記第２のユーザとの前記ゲーム上の関係度合を示す親密度が高いほど、前記第１のユーザの前記ゲーム上の結果が有利になるように、前記状況を設定してもよい。 ここで、親密度とは、第１のユーザと第２のユーザとの間の関係性の高さを一定の基準で数値化したものである。 このゲーム制御装置によれば、ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしている第２のユーザとの親密度が高いほど、第１のユーザは、より有利なゲーム上の結果を得ることができる。例えば、野球ゲームの場合、打者による打撃のイベントに先立ち設定される状況として、ランナーをどの塁に配置するか、というケースをとり得るが、この場合、上記親密度が高いほど、１塁よりは２塁、３塁にランナーを配置する、というようにすればよい。このため、第１のユーザには、より有利なゲーム上の結果を得るために、親密度の高いユーザと同時にアクセスすることが動機付けられ、そのユーザとさらに関係性が高くなるような仕組みとすることができる。

本発明の第２の観点は、野球を模擬したゲームを実行する
ゲーム制御装置である。 当該ゲーム制御装置は、 前記ゲーム上の打撃イベントに先立って、走者キャラクタの出塁状況を設定する設定手段と、 前記設定手段によって設定された出塁状況の下で、所定の操作入力に関する情報に基づいて、前記打撃イベントを発生させるイベント発生手段と、 前記設定手段によって設定された出塁状況と、前記イベント発生手段によって発生した前記打撃イベントに基づき、前記ゲーム上の結果を発生させる結果発生手段と、 を備える。

このゲーム制御装置では、設定された出塁状況の下で、所定の操作入力に関する情報に基づいて打撃イベントが発生すると、設定された出塁状況と打撃イベントとに基づきゲーム上の結果が得られる。これにより、ゲーム上の結果を得るために煩雑な操作入力を必要としないことから、ユーザは簡易な操作でゲームを行うことができる。また、設定された状況の下で良好なゲーム上の結果を得るために、所定の操作入力に関する情報に基づきどのような打撃イベントを発生させるかを、ユーザに検討させることができる。これにより、ゲーム上の結果が得られるまでの過程に対してユーザに関心を持たせることができ、ゲームの興趣性を高めることができる。

上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段と、ユーザからのアクセスに関する情報を取得する取得手段とを備え、前記設定手段は、前記取得手段が取得したアクセスに関する情報に基づいて、前記ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしている第２のユーザが抽出された場合に、前記第２のユーザと前記走者キャラクタとを対応付けた状態で前記走者キャラクタの出塁状況を設定してもよい。 このゲーム制御装置では、ゲームを実行中の第１のユーザとほぼ同時にゲームをプレイしている第２のユーザを走者キャラクタに見立てた状態で打撃イベントが行われるので、第１のユーザにとっては、第２のユーザとともに野球の試合を行っているような感覚が得られる。これにより、第１のユーザが、打撃イベントを契機として第２のユーザとの関係度合いを高めることを動機付けることができる。

上記ゲーム制御装置において、前記設定手段は、前記走者キャラクタが少なくとも一つの塁に存在する出塁状況が設定される場合に、前記第１のユーザと前記第２のユーザとの前記ゲーム上の関係度合を示す親密度が高いほど、前記第２のユーザに対応する走者キャラクタが、進塁する上で本塁に近い塁に配置されるように、出塁状況を設定してもよい。 これにより、ユーザが、関係度合いの高い仲間のユーザを本塁に生還させるために、集中して打撃イベントをプレイすることを動機付けることができる。

上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段と、ユーザからのアクセスに関する情報を取得する取得手段とを備え、前記設定手段は、前記取得手段が取得したアクセスに関する情報に基づいて、前記ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしている第２のユーザが抽出された場合に、前記第２のユーザに対応付けられた所定の値の合計が大きいほど、前記第１のユーザの前記ゲーム上の結果が有利になるように、前記状況を設定してもよい。なお、ここで、第２のユーザが１人という場合もあるが、この場合の所定の値も上記合計に相当するものとする。 ここで、「第２のユーザに対応付けられた所定の値」とは、例えば、第２のユーザのゲーム上の能力の高さやゲーム上における進行レベルや到達ステージ等を示すレベルであってもよいし、第２のユーザがゲーム上保有しているキャラクタやアイテム等の能力値、あるいは所定のポイント値などであってもよい。 このゲーム制御装置によれば、ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしている第２のユーザ（例えば、第１のユーザの仲間）に対応付けられた値の合計が大きいほど、第１のユーザは、より有利なゲーム上の結果を得ることができる。このため、第１のユーザには、より有利なゲーム上の結果を得るために、第２のユーザと同時にアクセスすることが動機付けられる。すなわち、ゲームへのアクセスを多くすれば互いのメリットが向上することを仲間同士で認識しているため、ゲーム全体のアクセス数の向上に自然に寄与でき、この結果、ゲームのコミュニティの活性化、ソーシャル性を高めることができる。また、上記メリットを得るために、ユーザが仲間に対して、ゲーム内のチャットやメール、その他の手段でアクセスを呼びかけることも想定されるので、よりゲームのコミュニティの活性化を図ることができる。

本発明の第３の観点は、現実世界の競技又は遊技を模擬したゲームを実行するゲーム制御装置におけるゲーム制御方法であって、 前記ゲーム上のイベントに先立って、前記競技又は遊技で実現可能な状況を設定するステップと、 設定された状況の下で、所定の操作入力に関する情報に基づいて、前記イベントを発生させるステップと、 設定された状況と、発生した前記イベントに基づき、前記ゲーム上の結果を発生させるステップと、 を備える。

本発明の第４の観点は、現実世界の競技又は遊技を模擬したゲームの実行を制御するために、コンピュータに、 前記ゲーム上のイベントに先立って、前記競技又は遊技で実現可能な状況を設定する機能、 設定された状況の下で、所定の操作入力に関する情報に基づいて、前記イベントを発生させる機能、及び 設定された状況と、発生した前記イベントに基づき、前記ゲーム上の結果を発生させる機能、 を実現させるためのプログラムである。

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

本発明の第５の観点は、通信端末と、当該通信端末からアクセスされ、前記通信端末によるゲームの実行を制御するゲーム制御装置と、を含み、現実世界の競技又は遊技を模擬したゲームを実行するゲームシステムであって、 前記ゲーム上のイベントに先立って、前記競技又は遊技で実現可能な状況を設定する設定手段と、 前記設定手段によって設定された状況の下で、所定の操作入力に関する情報に基づいて、前記イベントを発生させるイベント発生手段と、 前記設定手段によって設定された状況と、前記イベント発生手段によって発生した前記イベントに基づき、前記ゲーム上の結果を発生させる結果発生手段と、 を備える。

本発明の第６の観点は、現実世界の競技又は遊技を模擬したゲームの実行を制御するゲーム制御装置にアクセス可能な通信端末であって、 前記ゲーム上のイベントに先立って、前記競技又は遊技で実現可能な状況を示す情報を前記ゲーム制御装置から受信する受信手段と、 前記受信手段が受信した情報に示された状況の下で、所定の操作入力に関する情報に基づいて、前記イベントを発生させるイベント発生手段と、 前記情報に示された状況と、前記イベント発生手段によって発生した前記イベントに基づき、前記ゲーム上の結果を発生させる結果発生手段と、 を備える。

通信端末は、例えば携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機、通信機能付きゲーム装置等であってよい。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、通信端末によれば、ユーザが簡易な操作でゲームを行いつつ、ゲーム上の結果が得られるまでの過程に対して関心を持つことができる。

第１実施形態のゲームシステムの基本構成を示す図。 第１実施形態の通信端末の外観の例を示す図 第１実施形態の通信端末の構成を示すブロック図。 第１実施形態のゲームサーバの構成を示すブロック図。 第１実施形態のデータベースサーバの構成を示すブロック図。 データベースサーバに含まれるユーザデータベースの構成例を示す図。 トップページを表示する通信端末の表示画面の一例を示す図。 第１実施形態のゲームのウェブページの表示例を示す図。 第１実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための 機能ブロック図。 試合処理を実行するときの処理の一例を示すフローチャート。 試合処理におけるウェブページの表示例を示す図。 判別用データの内容を例示する図。 第１実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート 。 第２実施形態のゲーム制御装置で主要な役割を果たす機能を説明するため の機能ブロック図。 ログデータの内容を例示する図。 状況設定データの内容を例示する図。 図１３に示したフローチャートと異なる部分を説明するフローチャート。 親密度データの内容を例示する図。 変形例におけるウェブページの表示例を示す図。

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

（１−１）ゲームシステムの構成 図１は、第１実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(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）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。 図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。

本実施形態のゲームサーバ２０によって実行されるゲームは、現実世界の競技又は遊技を模擬したゲームであれば特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲームサーバ２０によって実現されるゲームの一例として、野球形式のデジタルカードゲームを採り上げる。 野球形式のデジタルカードゲームは、ユーザが野球選手に対応する選手カードを収集することによって自らのチームを作り上げ、他のユーザのチームと野球の対戦する、あるいは技能レベルごとの野球のリーグ戦を戦うように構成されているゲームである。野球形式のデジタルカードゲームには、自らのチームを作り上げていくために選手カードを探索するスカウト処理や、抽選によって選手カードを入手することを可能とする抽選処理、あるいは２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる強化処理等が設けられている。 野球形式のデジタルカードゲームに実装されている各機能については、後述する。

図６に、上述した野球形式のデジタルカードゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名／表示画像、チーム、技能レベル、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、仲間のユーザＩＤ、保有カードの画像データ、及び保有カードのパラメータの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。・ユーザ名／表示画像 ゲームの実行時に通信端末１０にユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。・チーム 上記野球形式のデジタルカードゲームにおいて、ユーザ登録時に、ユーザが指定するチームである。このゲームでは、例えば、Ｐ１〜Ｐ６の６チームからなるＰリーグ、Ｑ１〜Ｑ６の６チームからなるＱリーグが設けられており、ユーザはこの１２チームの中からいずれかのチームをユーザ登録時に選択する。・技能レベル ゲーム上のユーザの技能レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値であり、例えばスカウトを継続的に行うことで順次技能レベルが上がるように構成される。・行動ポイント 上記野球形式のデジタルカードゲームにおいて、例えばユーザによるゲーム上のスカウトを行う上で必要となるポイントである。行動ポイントは、スカウトを行うことで低減し、所定の時間が経過する毎に回復（増加）する値である。・運営ポイント 上記野球形式のデジタルカードゲームにおいて、例えばユーザによるゲーム上の対戦を行う上で必要となるポイントである。運営ポイントは、他のユーザとの対戦等によって低減し、所定の時間が経過する毎に回復（増加）する値である。・強化ポイント 上記野球形式のデジタルカードゲームにおいて、例えばユーザによる選手カードの強化を行う上で必要となるポイントである。強化ポイントは、選手カードの強化を行うことで低減し、他のユーザとの対戦で勝利するか、あるいは所定の時間が経過する毎に回復（増加）する値である。・エールポイント 上記野球形式のデジタルカードゲームにおいて、仲間のユーザへ応援メッセージを送信することでユーザが取得するポイントである。・選手数 ユーザが保有する選手カードの数である。選手数は、スカウト処理や強化処理の実行によって増減する。選手数の最大値（例えば、６０）は予め規定されている。・仲間のユーザＩＤ 対象とするユーザＩＤの仲間である他のユーザＩＤのデータである。・保有カードの画像データ 上記野球形式のデジタルカードゲームの場合、保有カードの画像データは、ユーザが保有する選手カードについての画像を含むデータである。・保有カードのパラメータ 保有カードのパラメータには、選手カードの能力値を示すデータが含まれる。例えば、図６に示すように、パラメータの項目として「打力」，「走力」，「守備力」等の各々の各能力値が含まれてもよい。図６の例では、能力値は０〜１０００の範囲の値であって、能力値が大きい値であるほど能力が高いことを示している。図６では、能力の指標としての項目として、「打力」，「走力」，「守備力」を例示しているが、選手が投手であれば別の項目、例えば「球速」，「制球力」，「スタミナ」等としてもよい。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されるゲームの設定についての情報や、ゲームの結果（ゲーム結果）に関する情報を記憶、更新する。ゲーム結果に関する情報は、ゲームの性質によって多様な情報
を含みうる。野球形式のデジタルカードゲームの場合を例に挙げれば、ゲーム結果に関する情報は、異なるユーザＩＤ同士の対戦の結果（スコア等）、特定の技能レベルの複数のユーザＩＤの間のリーグ戦の結果（スコア、ランキング等）、後述するミッション処理における得点結果などを含む。

（１−５）本実施形態のゲーム 以下、本実施形態のゲームに設けられている複数の処理のうちミッション処理について、具体的なゲームの流れを図７〜８を参照して説明する。図７は、本実施形態のゲームにおいて通信端末１０に表示されるトップページの一例を示す図である。図８は、ミッション処理において通信端末１０に表示されるウェブページの一例を示す図である。

図７に示すトップページは、個々のユーザＩＤに応じたウェブページで構成される。図７に例示されるトップページは、ユーザデータ表示領域、選手画像表示領域、メニュー表示領域を含む。 ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、ユーザ名、クラブ、技能レベル（レベル）、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、仲間の各項目のデータ（図６参照）が表示される領域である。 選手画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の選手カードのうちユーザによって予め指定された選手カードの画像が表示される領域である。 メニュー表示領域は、本実施形態のゲームに設けられる複数の処理（スカウト処理、強化処理、試合処理、抽選処理、オーダー処理、ミッション処理）に対応した基本メニューとして、「スカウト」、「強化」、「試合」、「抽選」、「オーダー」、「ミッション」の各メニューｍ１〜ｍ６が表示される領域である。つまり、ゲームで実行される複数の処理が各々割り当てられた複数のメニューが、通信端末１０に表示されるウェブページの所定の位置にそれぞれ配置される。なお、メニューｍ５に対応するオーダー処理は、ユーザの操作に応じて、選手カードのオーダー（例えば打順や守備位置等）の入れ替え、先発オーダーに設定された選手カードと控えの選手カードとの交替等を行う処理である。

本実施形態のゲームのミッション処理は、ユーザが打撃イベントを繰り返す間に獲得した得点の合計が、スリーアウトになる前に所定値（例えば１０点）以上に達した場合に特典を得る、というものである。本実施形態では、１回の打撃イベントの結果が１球で決まることとし、１回の打撃イベント毎にランナーの出塁状況が設定されるように構成されている。なお、特典が得られるための条件は任意に設定してよい。例えば、打撃イベントの結果が１回アウトになるまでに少なくとも１点を獲得すれば特典が得られるようにしてもよいし、スリーアウトになるまでに獲得した得点の合計が所定値以上に達した場合に特典が得られるようにしてもよい。また、付与される特典は、ゲーム上で任意に設定できる。例えば、特典は、一定量のエールポイントや強化ポイントなどであってもよいし、ゲーム内で入手するのが困難な選手カード（いわゆるレアカード）であってもよい。

本実施形態のゲームでは、図７に示すメニューｍ６の選択操作に応じて、図８に示すミッション処理が実行される。先ず、メニューｍ６の選択操作に応じて、図８（ａ）に示すようにウェブページが更新される。図８（ａ）に示すウェブページには、本塁と１〜３塁とを含むフィールドの画像が表示される領域と、現在のアウト数を色の変化により表す３つのマークと、現在の合計得点についての情報を表示するテキスト（図では現在の合計得点が０点であることを示す。）と、出塁するランナーの数（０〜３人のいずれか）を示すテキストが高速に切り替え表示される表示領域１００と、出塁するランナーの数を決定するためのメニューｍ２０などが含まれる。

図８（ａ）に示すウェブページにおいて、メニューｍ２０が選択操作されると、表示領域１００において高速に切り替え表示される数字（テキストに含まれる）の中からいずれかが決定される演出が行われ、出塁するランナーの数と、当該ランナーが配置される塁とが決定され、図８（ｂ）に示すようにウェブページが更新される。なお、ランナーの数、塁を決定する演出としては、上記のようにテキストを高速に切り替え表示する場合の他に、例えば、ダイヤモンドを構成する塁上にランナーが１人いる状態、２人いる状態、満塁の状態あるいはランナーがいない状態のそれぞれの状態を示す画像やテキストを高速に切り替え表示し、このいずれか決定されるようにしてもよい。ここで、ランナーの数と、当該ランナーが配置される塁とは、メニューｍ２０が選択操作されたタイミングに応じてランダムに決定されてもよいし、所定の規則性に基づいて決定されてもよい。図８（ｂ）には、１人のランナー（走者キャラクタＲＣ）が１塁に配置された場合のウェブページの表示例が示されている。なお、ランナーの出塁状況は、例えば「ワンアウトランナー３塁です。」等のように文字情報や音声情報等によってユーザが認識できるように構成されてもよい。また、図８（ｂ）に示すウェブページには、打撃（バッティング）方法を選択することを促すメッセージと、バッティング方法として「ミート」を選択するためのメニューｍ２１と、バッティング方法として「強振」を選択するためのメニューｍ２２などが含まれる。この場合、例えば、ランナーが満塁の場合に、少ない点でも着実に得点を獲得するために「ミート」を選択するか、あるいは一度に大量得点を獲得するために「強振」を選択するかを、ユーザが選択できるように構成されている。 メニューｍ２１またはメニューｍ２２がユーザによって選択操作されると、選択されたバッティング方法による打撃イベントが行われ、当該打撃イベントの結果（ヒットまたはアウト）が、所定の、あるいはランダムな確率で決定される。また、打撃イベントの結果がヒットの場合には、ヒットの内容（単打、２塁打、３塁打あるいは本塁打）が、所定の、あるいはランダムな確率で決定される。

打撃イベントの結果がヒットの場合には、図８（ｃ）に例示するウェブページに更新される。図８（ｃ）には、ヒットの内容が３塁打であった場合のウェブページの表示例が示されている。図８（ｃ）に示すウェブページには、ヒットの内容（図に示す例では３塁打）を示すテキスト等が表示される表示領域１０３と、ヒットの内容によって獲得した得点を示すテキスト（図に示す例では１点）の表示領域１０４などが含まれる。つまり、走者キャラクタＲＣが１塁に配置された状況において３塁打が出たことにより、獲得した得点は１点となる。獲得した得点は、合計得点に加算される。 ここで、獲得した合計得点が所定値以上に達すると、ユーザに対して特典が付与され、ミッション処理が終了する。また、獲得した合計得点が所定値未満の場合には、再度、図８（ａ）に例示するウェブページ上においてランナー数を決定する処理に移行する。ここで、再度ランナー数を決定する処理に移行する場合、それまでに獲得した合計得点と、アウト数とが保持される。

一方、打撃イベントの結果がアウトの場合には、アウト数が１つ加算され、図８（ｄ）に例示するウェブページに更新される。図８（ｄ）には、ノーアウトからワンアウトになった場合のウェブページの表示例が示されている。図８（ｄ）に示すウェブページには、打撃イベントの結果（図に示す例ではアウト）を示すテキストの表示領域１０５などが含まれる。図８（ｄ）に例示したウェブページでは、アウト数を表す３つのマークのうち一つのマークの色が変化した状態で表示されることにより、現在のアウト数を認識できるようになっている。 なお、アウト数が３（すなわちスリーアウト）に達すると、ミッション処理が終了する。また、アウト数が３未満の場合には、再度、図８（ａ）に例示するウェブページ上においてランナー数を決定する処理に移行する。ここで、再度ランナー数を決定する処理に移行する場合、それまでに獲得した合計得点と、アウト数とが保持される。

（１−６）ゲーム制御装置における各機能の概要 本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述した野球形式のデジタルカードゲーム（以下、適宜単に「ゲーム」という。）が適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図９を参照して説明する。図９は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。 なお、図９の機能ブロック図において、設定手段５３、イベント発生手段５４及び結果発生手段５５が本発明の主要な構成に対応している。その他の手段は必ずしも必須の構成ではないが、本発明をさらに好ましくするための構成である。 なお、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネルの操作によるウェブページのスクロール操作によって変化しうる。

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

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

ゲーム進行手段５２は、通信端末１０に対するユーザの操作に応じて、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータを送信することで、ゲームを進行させる。前述したように、野球形式のデジタルカードゲームには、ゲームを進行させる上で以下の処理が設けられている。・スカウト処理： 自らのチームを作り上げていくために選手カードを探索する処理である。スカウトを実行することで行動ポイントは消費するが、強化ポイントは増加する。・強化処理： 強化ポイントを消費することで、２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる処理・試合処理： 他のユーザのチームと野球の試合を行う処理である。試合を行うことで運営ポイントは消費するが、試合に勝利すれば強化ポイントが増加する。・抽選処理： エールポイントを消費して、抽選によって選手カードを入手する処理である。・オーダー処理： ユーザが選手カードのオーダーの入れ替え、控えの選手カードとの交替等を実行するための処理である。・ミッション処理： 図８に関連して説明したように、ランナーの出塁状況に応じてバッティング方法を選択することにより、得点を獲得するための処理である。

なお、ゲーム進行手段５２を実現するに当たり、ゲームサーバ２０のＣＰＵ２１は、ウェブページ上に表示される各メニューに、ゲームを進行させるためのいずれかの処理を予め割り当てている。そして、ＣＰＵ２１は、通信端末１０においてウェブページ上のメニューが選択されたときに、選択されたメニューについての情報を通信端末１０から受信し、受信した情報に基づいて、選択されたメニューに割り当てられた処理を実行する。

ゲーム進行手段５２は、図７に示したように、ゲームで実行される複数の処理が各々割り当てられた複数のメニューを通信端末１０に表示させる。具体的には、ＣＰＵ２１は、複数のメニューを含むウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。上述したように、ゲームでは、スカウト処理、強化処理、試合処理及び抽選処理の各処理の実行に伴ってゲーム上のポイントが消費される。

例えば図７に示すトップページをユーザの通信端末１０に表示する場合について、ゲーム進行手段５２の機能は以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、データベースアクセス部２４を介してユーザデータベース３１にアクセスし、ユーザデータ表示領域に含まれる各項目のデータと、選手画像表示領域に表示すべき選手カードの画像データを読み出す。次にＣＰＵ２１は、図７に示したトップページが構成されるようにＨＴＭＬデータを生成し、通信端末１０宛に送信する。生成されるＨＴＭＬデータは、ユーザごと（つまり、ユーザＩＤごと）に異なるものとなる。通信端末１０は、受信したＨＴＭＬデータを解釈してトップページの画像を表示部１６（表示画面１６ａ）に表示する。

ゲーム進行手段５２は、通信端末１０に表示されたメニューに対するユーザの選択操作に応じて、それぞれスカウト処理、強化処理、試合処理、抽選処理及びミッション処理の各処理の実行を開始する。つまり、複数のメニューのいずれかを選択操作することによって、ゲームを構成する各処理の実行が開始される。好ましくは、各処理の実行が開始された場合、処理ごとに階層的に細分化された複数のメニューを含むようにしてウェブページが更新されつつ各処理が実行される。

［試合処理］ ゲーム進行手段５２は、他のユーザのチームと野球の対戦を行う試合処理を実行する機能を有する。

ゲーム進行手段５２は、図１０〜１１を参照すると、例えば以下のとおり実現される。図１０は、ゲーム進行手段５２が試合処理を実行する機能を実現するために、主としてゲームサーバ２０のＣＰＵ２１によって実行される一連の処理を示すフローチャートである。図１１は、ゲーム進行手段５２の機能により実現される、ユーザの通信端末１０上に表示されるウェブページの例を示す図である。

あるユーザＩＤに対応するユーザの通信端末１０のトップページ上でメニューｍ３（図７参照）の選択操作がなされ、その選択結果を受信すると、ゲームサーバ２０のＣＰＵ２１は、そのユーザＩＤの対戦相手の複数の候補を、ユーザデータベース３１に含まれる他のユーザＩＤの中からランダムに決定する。このとき、対戦するユーザの候補の技能レベルは、メニューｍ３を選択操作したユーザと同一の技能レベルであることが好ましい。ＣＰＵ２１は、複数の対戦相手の候補のリストからいずれかの候補を選択可能とするウェブページを表示するためのＨＴＭＬデータをユーザの通信端末１０宛に送信する（ステップＳ１０）。複数の対戦相手の候補のリストからいずれかの候補を選択する操作がユーザによってなされると（ステップＳ１２：ＹＥＳ）、図１１（ａ）に示すように、対戦相手ととともに試合開始の指示を促すメニューを含むウェブページが表示される。ここで、ユーザが「試合開始」のメニューを選択すると（ステップＳ１４：ＹＥＳ）、ＣＰＵ２１は対戦結果を決定する処理を行う。対戦結果を決定するに当たって、ＣＰＵ２１は、データベースアクセス部２４を介してデータベースサーバ３０のユーザデータベース３１にアクセスし、対象となるユーザＩＤの運営ポイントが試合の実行に必要とする所定量以上である場合に、運営ポイントからその所定量を減少させるとともに、対戦相手となる２つのユーザＩＤに対応付けられた複数の選手カードの能力を示すパラメータを読み出す。そして、ＣＰＵ２１は、読み出したパラメータに基づいてユーザ間の対戦結果を決定する（ステップＳ１６）。なお、ステップＳ１２において、対戦相手が選択されない場合（ステップＳ１２：ＮＯ）には、ＣＰＵ２１は、ステップＳ１２の処理を再度行う。また、ステップＳ１４において、「試合開始」のメニューが選択されない場合（ステップＳ１４：ＮＯ）には、ＣＰＵ２１は、ステップＳ１２の処理を再度行う。

対戦結果の決定方法は、選手カードのパラメータがその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、対戦相手となる２人のユーザが保有する複数の選手カードのパラメータの合計値を比較し、合計値が大きな方のユーザが高い確率（例えば、６０〜９０％の範囲内の所定の確率）をもって勝利するように設定してもよい。この勝率は、パラメータの合計値の差が大きいほど高い確率としてもよい。このとき、図６に示したように、能力値を示すパラメータの項目が複数存在する場合には、各選手カードのパラメータを代表する値として、各項目のパラメータの値に対して所定の重み付け（例えば、図６の例では、「打力」を０．４、「走力」を０．２、「守備力」を０．４の重み付けにする等）をもって総合的な能力値を設定してもよい。

ＣＰＵ２１は、対戦結果を決定すると対戦結果をユーザに通知するために、その対戦結果を含むウェブページを表示させるＨＴＭＬデータを、「試合開始」のメニューの選択操作を行ったユーザの携帯端末１０宛に送信する（ステップＳ１８）。「試合開始」のメニューを選択する操作が行われてから、対戦結果を含むウェブページが表示されるまでの時間は極めて短時間（例えば数秒）であるため、ユーザは、簡易な操作のみで極めて短期間で対戦結果を知ることができる。図１１（ｂ）は、対戦処理の実行によって表示されるウェブページの一例を示す図である。図１１（ｂ）に例示したウェブページでは、例えばスコア等を含む試合結果が表示される。

［ミッション処理］ 図８に関連して説明したように、ミッション処理は、ランナー（走者キャラクタＲＣ）の出塁状況に応じてバッティング方法を選択することにより、得点を獲得していく処理である。ミッション処理は、設定手段５３、イベント発生手段５４、結果発生手段５５及び特典付与手段５６によって実行される。

設定手段５３は、ゲーム上のイベントに先立って、現実世界の競技又は遊技で実現可能な状況を設定する機能を備える。ここで、「イベント」とは、ゲームにおいて模擬された現実世界の競技又は遊技において起こり得る事象であれば任意に選択することができる。例えば、本実施形態のゲームのように野球ゲームの場合には、イベントは、図８に例示した打撃イベントに限られず、投球あるいは走塁等のイベントであってよい。例えば、サッカーゲームの場合には、イベントは、ペナルティーキックのイベントであってもよいし、コーナーキックのイベントであってもよい。また、「競技又は遊技で実現可能な状況」とは、例えば、本実施形態のゲームのように野球ゲームの場合には、図８に例示したように塁上にランナーが配置されている状況に限られず、打者に向かってボールが飛んでくる状況であってもよい。なお、打撃イベントは、本発明の「イベント」の一例である。また、走者キャラクタＲＣの出塁状況は、本発明の「競技又は遊技で実現可能な状況」の一例である。 設定手段５３の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、図８（ａ）に示すウェブページを表示するためのＨＴＭＬデータを生成し、無線通信インタフェース部２５を介して通信端末１０宛に送信する。そして、図８（ａ）に示すウェブページ上でメニューｍ２０が選択操作されると、ＣＰＵ２１は、ランナーの数と、当該ランナーが配置される塁とをランダムに決定する。なお、ＣＰＵ２１は、ランナーの数と、ランナーが配置される塁とを、所定の規則性に基づいて決定してもよい。ＣＰＵ２１は、ランナー（走者キャラクタＲＣ）の数及び配置に基づいて、図８（ｂ）に示すウェブページを表示するためのＨＴＭＬデータを生成し、通信端末１０宛に送信する。

イベント発生手段５４は、設定手段５３によって設定された状況の下で、所定の操作入力に関する情報に基づいて、打撃イベント（イベント）を発生させる機能を備える。ここで、「所定の操作入力に関する情報」とは、例えば、ゲームサーバ２０にアクセス可能な外部装置に対して所定の操作入力が行われたことを示す情報であってもよい。 イベント発生手段５４の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、図８（ｂ）に示したウェブページ上でメニューｍ２１あるいはメニューｍ２２の何れかが選択操作されることにより、「ミート」に対応する打撃イベントと、「強振」に対応する打撃イベントの何れを発生させるかを判別する。

結果発生手段５５は、設定手段５３によって設定された状況と、イベント発生手段５４によって発生した打撃イベント（イベント）に基づき、ゲーム上の結果を発生させる機能を備える。ここで、「ゲーム上の結果」とは、ゲーム全体の結果に限られず、ゲーム内の一部の局面における結果であってもよい。本実施形態の例では、「ゲーム上の結果」とは、１回の打撃イベントで獲得した得点であるが、例えば、打撃結果（ヒット又はアウト）であってもよいし、試合の対戦結果でもよい。また、本実施形態の例では、「状況」とは、走者キャラクタＲＣの出塁状況である。 結果発生手段５５は、打撃イベントの結果（ヒット又はアウト）を判別する。打撃イベントの結果の判別方法については、図１２に例示する判別用データに基づき判別してもよい。図１２を参照し、判別用データについて説明する。図１２（ａ）には、「ミート」に対応する打撃イベントが発生した場合の判別用データの一例が示されている。図１２（ｂ）には、「強振」に対応する打撃イベントが発生した場合の判別用データの一例が示されている。各判別用データは、１球目（１打席目）〜９球目（９打席目）の球数と、アウト数とに応じて、「ミート」あるいは「強振」の打撃イベントが発生したときにヒット又はアウトになる確率が設定
されている。例えば、ノーアウトで１球目に、「ミート」の打撃イベントが発生したときには、９５％の確率でヒットとなる。一方、例えば、ノーアウトで１球目に、「強振」の打撃イベントが発生したときには、ヒットになる確率は７０％である。なお、図１２（ａ），（ｂ）に記載された確率の値は例示であり、確率の値は適宜設定されうる。また、図１２（ａ），（ｂ）に例示された判別用データでは、９球目で必ずスリーアウトになるように設定されているが、球数は制限されなくてもよい。

また、結果発生手段５５は、打撃イベントの結果をヒットと判別した場合に、当該打撃イベントのヒットの内容（単打、２塁打、３塁打あるいは本塁打のいずれか）を決定する。ヒットの内容は、打撃イベントに対応するバッティング方法毎に任意に設定されてもよい。例えば、「ミート」の打撃イベントの場合には、単打が６５％、２塁打が２０％、３塁打が１０％、本塁打が５％の確率となるように決定されてもよい。また、「強打」の打撃イベントの場合には、例えば、単打が１０％、２塁打が５０％、３塁打が２５％、本塁打が１５％の確率となるように決定されてもよい。なお、これらの確率の値は、予めＲＯＭ２２に記録されてもよい。ＣＰＵ２１は、打撃イベントの結果をヒットと判別した場合、打撃イベントに対応するバッティング方法についてのヒットの内容を、ＲＯＭ２２に記録された確率の値に基づき決定する。

結果発生手段５５は、走者キャラクタＲＣの出塁状況とヒットの内容とに基づいて、１回の打撃イベントでユーザが獲得した得点の値をもとめる。なお、走者キャラクタＲＣの出塁状況の全てのパターン毎に、ヒットの内容に応じて獲得される得点を示したテーブル情報が予めＲＯＭ２２に記録されていてもよい。具体的には、ＣＰＵ２１は、走者キャラクタＲＣの出塁状況とヒットの内容とを用いて、当該テーブル情報を参照することにより獲得される得点を求める。また、ＣＰＵ２１は、合計得点に対して、獲得された得点を加算する。なお、合計得点は、ＲＡＭ２３に記録されてもよい。

特典付与手段５６は、結果発生手段５６によって発生したゲーム上の結果に基づき、ユーザに対して特典を付与する機能を備える。本実施形態では、特典付与手段５６は、ミッション処理において、スリーアウトになる前にユーザが獲得した合計得点の値が所定値（例えば１０点）以上の場合に、当該ユーザに対して特典を付与する。なお、スリーアウトになるまでにユーザが獲得した合計得点の値に応じて、当該ユーザに付与される特典の内容が変動するようにしてもよい。例えば、ユーザが獲得した合計得点の値が大きいほど、ゲーム上、より高価な特典が付与されるようにしてもよい。特典の内容は特に問わないが、例えばゲーム上で利用可能なポイント（例えば、所定量のエールポイントや強化ポイント等）であってもよいし、ゲーム内で入手するのが困難な選手カード（いわゆるレアカード）であってもよい。 特典付与手段５６の機能は、以下のようにして実現できる。なお、ユーザに対して付与する特典の内容については、予めＲＯＭ２２に記録されているものとする。ＣＰＵ２１は、１回のミッション処理が終了するまでにユーザが所定値以上の得点を獲得すると、ＲＯＭ２２を参照して、当該ユーザに対して特典を付与する処理を行う。なお、特典を付与する処理とは、付与対象となるユーザのユーザＩＤと、付与されるポイントやアイテムを関連付ける処理であってよい。例えば、特典として付与された強化ポイントをユーザに与える場合、ＣＰＵ２１は、付与対象となるユーザのユーザＩＤのユーザデータにおける強化ポイントを書き換える処理（与えられたポイントを加算する処理）を行ってよい。

（１−７）本実施形態のゲーム制御装置の主要な処理のフロー 次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１３のフローチャートを参照して説明する。図１３のフローチャートは、主として設定手段５３、イベント発生手段５４、結果発生手段５５及び特典付与手段５６によって実行される処理である。

図７のウェブページ上でメニューｍ６が選択されたことを認識すると、ゲームサーバ２０のＣＰＵ２１は、図８（ａ）に示すウェブページを表示するためのＨＴＭＬデータを通信端末１０宛に送信する。これにより、図８（ａ）に示すウェブページが通信端末１０上に表示される（ステップＳ１１０）。次に、図８（ａ）に示すウェブページ上で「決定」メニューｍ２０が選択されたことを認識すると（ステップＳ１２０：ＹＥＳ）、ＣＰＵ２１は、ランナー（走者キャラクタＲＣ）の数及び配置を設定する（ステップＳ１３０）。そして、ＣＰＵ２１は、図８（ｂ）に示すウェブページを表示するためのＨＴＭＬデータを通信端末１０宛に送信する（ステップＳ１４０）。このとき、ユーザは、走者キャラクタＲＣの数及び配置に基づき、バッティング方法を自らの好みに応じて選択することが可能となる。

次に、図８（ｂ）に示すウェブページ上で「ミート」メニューｍ２１あるいは「強振」メニューｍ２２が選択されたことを認識すると（ステップＳ１５０：ＹＥＳ）、ＣＰＵ２１は、図１２に示した判別用データに基づいて、打撃結果（ヒット又はアウト）を決定する（ステップＳ１６０）。そして、打撃結果がヒットの場合には（ステップＳ１７０：ＹＥＳ）、ＣＰＵ２１は、ヒットの内容を決定する（ステップＳ１８０）。次に、ＣＰＵ２１は、ヒットの内容及び走者キャラクタＲＣの出塁状況に基づき、獲得した得点をもとめる（ステップＳ１９０）。ＣＰＵ２１は、ステップＳ１８０の処理において決定したヒットの内容と、ステップＳ１９０の処理においてもとめた得点とを含むウェブページを表示するためのＨＴＭＬデータを通信端末１０宛に送信する（ステップＳ２００）。そして、ＣＰＵ２１は、ステップＳ１９０の処理においてもとめた得点を合計得点に加算することにより、得点の合計を更新する（ステップＳ２１０）。次に、ＣＰＵ２１は、得点の合計が所定値（例えば１０点）以上に達すると（ステップＳ２２０：ＹＥＳ）、ユーザに得点を付与する（ステップＳ２３０）。なお、ステップＳ２２０の処理において、得点の合計が所定値未満の場合には、ＣＰＵ２１は、ステップＳ１１０の処理に移行する。

上記ステップＳ１７０の処理において、打撃結果がアウトの場合には、ＣＰＵ２１は、ＲＡＭ２３に記憶されているアウト数を１つ増加する（ステップＳ２４０）。次に、ＣＰＵ２１は、図８（ｄ）に示すウェブページを表示するためのＨＴＭＬデータを通信端末１０宛に送信する（ステップＳ２５０）。そして、アウト数が３に達すると（ステップＳ２６０：ＹＥＳ）、ＣＰＵ２１は、ミッション処理を終了する。なお、ステップＳ２６０の処理において、アウト数が３未満の場合には、ＣＰＵ２１は、ステップＳ１１０の処理に移行する。

上述したように、第１実施形態のゲーム制御装置によれば、設定された出塁状況の下で、所定の操作入力に関する情報に基づいて打撃イベントが発生すると、設定された出塁状況と打撃イベントとに基づき得点を獲得することができる。これにより、得点の値は、単に、操作入力に関する情報に基づいて決定されるのではなく、打撃イベントに先立って設定された出塁状況によっても影響を受けることになる。このため、得点を獲得するまでの過程に対してもユーザに関心を持たせることができる。したがって、従来のゲームの課題である、結果のみがわかればよいといった単調なゲーム性を解消することができ、ゲームの興趣性を高めることができる。 例えば、本実施形態のゲームのように野球ゲームの場合には、打者による打撃のイベントに先立ち設定される状況として、塁上にランナーが何人いるか、というケースをとり得る。この場合、ランナーが多いほど得点チャンスや得点数が増える可能性があるため、ユーザはこの設定状況に関心を持つことになり、得点の値が決定されるまでの経過にも興味を持つことになる。

（２）第２実施形態 以下、本発明の第２実施形態について説明する。 第１実施形態では、走者キャラクタＲＣの出塁状況がランダムに設定されていたのに対し、第２実施形態では、走者キャラクタＲＣの出塁状況が、ゲームを実行中のユーザの仲間数に基づいて設定される点において異なる。 以下、第１実施形態と異なる構成について説明する。

第２実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図を図１４に示す。図１４に示す機能ブロック図は、図９に示したものと比較して取得手段５７及び算出手段５８が追加された点で異なる。

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

取得手段５７の機能は以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、ユーザＩＤに基づくアクセスがある度に、そのアクセスに関する情報をゲームデータベース３２内のログデータに記録する。図１５にログデータの構成例を示す。図１５に示すように、ログデータは、ユーザＩＤ、アクセスの時刻の情報が、アクセスがあった時刻の順に記述されたデータである。例えば、ＣＰＵ２１は、図７に示すトップページを表示するためのＨＴＭＬデータの送信要求を受信したときに、ユーザＩＤ及びアクセスの時刻の情報をログデータに記録してもよいし、図７に示すトップページのメニューｍ６が選択操作されたことを認識したときにユーザＩＤ及びアクセスの時刻の情報をログデータに記録してもよい。 算出手段５８は、取得手段５７が取得したアクセスに関する情報に基づいて、ゲームを実行中のユーザ（第１のユーザ）と仲間の関係にあって、かつ所定期間内にアクセスしているユーザ数を算出する機能を備える。ここで、所定期間の起算点については２通りの方法を採ることができる。１つの方法は、プレイ中のユーザがログインした時刻を基準として、その時刻（基準時刻という。）の所定時間内にアクセスしている仲間のユーザの数を算出する方法である。もう１つの方法は、プレイ中のユーザがゲーム上の操作入力を行うことによりアクセスが行われた時刻を基準にして、その時刻（基準時刻という。）の所定時間内にアクセスしている仲間のユーザの数を算出する方法である。後者の方法はアクセスする度にユーザ数を算出することになるためＣＰＵ２１の負荷が掛かるが、算出されるユーザ数の精度が高くなる。つまり、ユーザは、ログインしてから集中的にアクセスを行うとは限らないため、ログインの時刻を基準とするよりもユーザ数の算出精度が高くなる。

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

本実施形態では、設定手段５３は、算出手段５８によって算出されたユーザ数の値が大きいほど、ゲームを実行中のユーザ（第１のユーザ）のゲーム上の結果が有利になるように、状況を設定する機能を備える。ここで、「ゲーム上の結果が有利になるように、状況を設定する」とは、例えば、「ゲーム上の結果」を得点としたとき、ランナーが満塁の状況になるように設定することであってもよいし、２塁または３塁にランナー
を配置することであってもよい。また、設定手段５３は、図１６に例示する状況設定データに基づいて出塁状況を設定してもよい。図１６に例示する状況設定データは、ゲームデータベース３２に記憶されており、ログインしている仲間の数と、その数に対応するランナー（走者キャラクタＲＣ）の数及び配置とを含む。図１６に例示する状況設定データでは、ログインしている仲間の数が多くなるほど、ゲームを実行中のユーザが高得点を獲得しやすくなるように走者キャラクタＲＣが配置される。 設定手段５３の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、図８（ａ）に示すウェブページを表示するためのＨＴＭＬデータを生成し、無線通信インタフェース部２５を介して通信端末１０宛に送信する。そして、図８（ａ）に示すウェブページ上でメニューｍ２０が選択操作されると、ＣＰＵ２１は、図１６に例示する状況設定データに基づいて、ランナーの数と、当該ランナーが配置される塁とを決定する。なお、ＣＰＵ２１は、ランナーの数と、ランナーが配置される塁とを、所定の規則性に基づいて決定してもよい。ＣＰＵ２１は、図８（ｂ）に示すウェブページを表示するためのＨＴＭＬデータを生成し、通信端末１０宛に送信する。

次に、本実施形態のゲーム制御装置の処理のフローの一例について、図１７のフローチャートを参照して説明する。なお、図１７のフローチャートは、図１３に示したフローチャートと異なる部分を説明するフローチャートであり、図１３と共通する部分については同じ符号を用いている。図１７のフローチャートは、主として設定手段５３及び算出手段５８によって実行される処理である。

まず、図８（ａ）に示すウェブページ上で「決定」メニューｍ２０が選択されたことを認識すると（ステップＳ１２０：ＹＥＳ）、ＣＰＵ２１は、図１５に示したログデータを参照して、ゲームを実行中のユーザの仲間のユーザのうち所定時間内にアクセスしているユーザ数を算出する（ステップＳ１３１）。次に、ＣＰＵ２１は、図１６に示した状況設定データを参照し、走者キャラクタＲＣの数及び配置を設定する（ステップＳ１３２）。そして、ＣＰＵ２１は、図８（ｂ）に示すウェブページを表示するためのＨＴＭＬデータを通信端末１０宛に送信する（ステップＳ１４０）。以降の処理は、図１３のフローチャートと同様である。

上述したように、第２実施形態のゲーム制御装置によれば、第１実施形態のゲーム制御装置の効果に加え、ゲームを実行中のユーザ（第１のユーザ）と関係付けられ、かつ所定期間内にアクセスしている仲間のユーザ数の値が大きいほど、ユーザは、より有利なゲーム上の結果を得ることができる。このため、第１のユーザには、より有利なゲーム上の結果を得るために、仲間のユーザと同時にアクセスすることが動機付けられる。すなわち、ゲームへのアクセスを多くすれば互いのメリットが向上することを仲間同士で認識しているため、ゲーム全体のアクセス数の向上に自然に寄与でき、この結果、ゲームのコミュニティの活性化、ソーシャル性を高めることができる。また、上記メリットを得るために、ユーザが仲間に対して、ゲーム内のチャットやメール、その他の手段でアクセスを呼びかけることも想定されるので、よりゲームのコミュニティの活性化を図ることができる。

（３）変形例 （３−１）変形例１ 上記第２実施形態において、設定手段５３は、打撃イベントが２回以上連続して発生する場合には、２回目以降の打撃イベントに先立って走者キャラクタＲＣの出塁状況を設定するときに、仲間のユーザ数に代えて、仲間のユーザ数から打撃イベント毎に値を減らしたユーザ数に基づいて、前記出塁状況を設定してもよい。 例えば、打撃イベントが繰り返し行われる毎に、同じユーザ数に基づいて出塁状況が設定される場合には、ユーザ数の値が大きければ、高得点を得ることの可能な出塁状況が常に設定されることから、仲間の数が多いユーザが突出して有利になってしまい、全体的なゲームのバランスが偏ってしまう可能性がある。一方、本変形例のゲーム制御装置によれば、打撃イベントの経過に従って、仲間のユーザ数を低減させていき、この低減された数に基づいて、出塁状況の設定が行われるので、上記のようなバランスの偏りを抑制することができる。

本変形例における設定手段５３の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、図１７に示したフローのステップＳ１３１の処理において算出した仲間のユーザ数をＲＡＭ２３に記憶する。ここで、ＣＰＵ２１は、例えば、２回目以降の打撃イベントでは打撃イベント毎にＲＡＭ２３に記憶されたユーザ数を１つずつ減らしていくようにしてもよい。この場合、１回目の打撃イベントにおいて算出された仲間のユーザ数が５人であった場合、図１６に示した状況設定データを参照すると、走者キャラクタＲＣは１〜３塁にそれぞれ配置される。次いで、２回目の打撃イベントでは、ＲＡＭ２３に記憶されているユーザ数は１つ減少して４人になっているので、走者キャラクタＲＣは２塁及び３塁に配置されることになる。これにより、ランナーの数が１人減ったため、１回目の打撃イベントと比較して高得点が得られ難い状況となる。

（３−２）変形例２ 上記第２実施形態において、設定手段５３は、取得手段５４が取得したアクセスに関する情報に基づいて、ゲームを実行中のユーザと関係付けられ、かつ所定期間内にアクセスしている仲間のユーザが抽出された場合に、前記ユーザと前記仲間のユーザとのゲーム上の関係度合を示す親密度が高いほど、前記ユーザの前記ゲーム上の結果が有利になるように、走者キャラクタＲＣの出塁状況を設定してもよい。

ここで、親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものである。親密度のデータ（親密度データ）の一例を図１８に示す。図１８に示す親密度データの例では、各ユーザの仲間のユーザ（ユーザＩＤ）と対応付けて、ユーザ間の応援メッセージの送信あるいは受信の頻度（応援頻度）、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数（プレゼント回数）などが記録され、これらの頻度や回数に基づいて一定の基準で親密度の値が設定される。応援頻度やプレゼント回数が多いほど親密度が高く設定される。また、一定の基準では、親密度の設定の基礎となる項目（図１８では、応援頻度やプレゼント回数など）ごとに、重み付けを考慮したものであってもよい。例えば、応援頻度が少なくてもプレゼント回数が多い場合に親密度を高く設定してもよい。このような親密度データは、例えば、ユーザデータベース３１内に記録される。

これにより、ゲームを実行中のユーザと、仲間のユーザとの親密度が高いほど、ゲームを実行中のユーザは、より有利なゲーム上の結果を得ることができる。例えば、野球ゲームの場合、打者による打撃のイベントに先立ち設定される状況として、ランナーをどの塁に配置するか、というケースをとり得るが、この場合、上記親密度が高いほど、１塁よりは２塁、３塁にランナーを配置する、というようにすればよい。このため、ユーザには、より有利なゲーム上の結果を得るために、親密度の高いユーザと同時にアクセスすることが動機付けられ、そのユーザとさらに関係性が高くなるような仕組みとすることができる。

設定手段５３の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ユーザデータベース３１内のユーザデータと親密度データをユーザＩＤごとに紐付けて管理している。ＣＰＵ２１は、例えば応援メッセージの送受信やプレゼントの仲間の間での送受信を、無線通信インタフェース部２５を介して送信先のユーザの要請に基づいて行っている。このような送受信が生ずると、ＣＰＵ２１は、対象となる親密度データを逐次更新する。 また、設定手段５３は、プレイ中のユーザとの間の親密度が所定の閾値よりも高いユーザを抽出すると、例えば、走者キャラクタＲＣが１〜３塁の全てに配置されるように出塁状況を設定してもよいし、走者キャラクタＲＣが２塁及び３塁に配置されるように出塁状況を設定してもよい。

（３−３）変形例３ 上記第２実施形態において、設定手段５３は、取得手段５７が取得したアクセスに関する情報に基づいて、ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしている第２のユーザが抽出された場合に、前記第２のユーザと走者キャラクタＲＣとを対応付けた状態で走者キャラクタＲＣの出塁状況を設定してもよい。 これにより、ゲームを実行中のユーザ（第１のユーザ）とほぼ同時にゲームをプレイしている仲間のユーザ（第２のユーザ）を走者キャラクタＲＣに見立てた状態で打撃イベントが行われるので、ゲームを実行中のユーザにとっては、仲間のユーザとともに野球の試合を行っているような感覚が得られる。このため、ユーザが、仲間のユーザとの関係度合いを高めることを動機付けることができる。

この場合、ＣＰＵ２１は、ログデータを参照して所定期間内にアクセスしている仲間のユーザを抽出し、抽出した仲間のユーザのユーザＩＤと走者キャラクタＲＣとを対応付ければよい。なお、ＣＰＵ２１は、例えば、図１９に示すように、走者キャラクタＲＣ１，ＲＣ２のそれぞれの近傍に仲間のユーザの表示名を表示する領域２００，２０１を設けたウェブページを通信端末１０上に表示させてもよい。

（３−４）変形例４ 上記第２実施形態において、設定手段５３は、走者キャラクタＲＣが少なくとも一つの塁に存在する出塁状況が設定される場合に、ゲームを実行中のユーザ（第１のユーザ）と当該ユーザの仲間のユーザ（第２のユーザ）との親密度が高いほど、仲間のユーザに対応する走者キャラクタＲＣが、進塁する上で本塁に近い塁に配置されるように、出塁状況を設定してもよい。 これにより、ユーザが、関係度合いの高い仲間のユーザを本塁に生還させるために、集中して打撃イベントをプレイすることを動機付けることができる。 本変形例の設定手段５３では、ＣＰＵ２１は、走者キャラクタＲＣを少なくとも一つの塁に存在する出塁状況を設定する場合、走者キャラクタＲＣが存在する塁のうち、進塁する上で本塁に近い塁（３塁、２塁、１塁の順）に配置された走者キャラクタＲＣに対して、親密度の高い仲間のユーザを対応付ければよい。

（３−５）変形例５ 上記第２実施形態において、設定手段５３は、取得手段５７が取得したアクセスに関する情報に基づいて、ゲームを実行中のユーザ（第１のユーザ）と関係付けられ、かつ所定期間内にアクセスしている仲間のユーザ（第２のユーザ）が抽出された場合に、前記仲間のユーザに対応付けられた所定の値の合計が大きいほど、ゲームを実行中のユーザのゲーム上の結果が有利になるように、出塁状況を設定してもよい。なお、ここで、第２のユーザが１人という場合もあるが、この場合の所定の値も上記合計に相当するものとする。 ここで、「仲間のユーザに対応付けられた所定の値」とは、例えば、仲間のユーザのゲーム上の能力の高さやゲーム上における進行レベルや到達ステージ等を示すレベルであってもよいし、仲間のユーザがゲーム上保有しているキャラクタやアイテム等の能力値、あるいは所定のポイント値などであってもよい。 このゲーム制御装置によれば、ゲームを実行中のユーザの仲間のうち所定期間内にアクセスしている仲間のユーザに対応付けられた値の合計が大きいほど、ゲームを実行中のユーザは、より有利なゲーム上の結果を得ることができる。このため、ゲームを実行中のユーザには、より有利なゲーム上の結果を得るために、仲間のユーザと同時にアクセスすることが動機付けられる。すなわち、ゲームへのアクセスを多くすれば互いのメリットが向上することを仲間同士で認識しているため、ゲーム全体のアクセス数の向上に自然に寄与でき、この結果、ゲームのコミュニティの活性化、ソーシャル性を高めることができる。また、上記メリットを得るために、ユーザが仲間に対して、ゲーム内のチャ
ットやメール、その他の手段でアクセスを呼びかけることも想定されるので、よりゲームのコミュニティの活性化を図ることができる。

本変形例における設定手段５３の機能は、以下のようにして実現される。なお、以下の説明では、「仲間のユーザに対応付けられた所定の値」の一例として、仲間のユーザのユーザＩＤに対応付けられた技能レベルを用いているが、例えば、仲間のユーザのユーザＩＤに対応付けられた各種ポイント（行動ポイント、運営ポイント、強化ポイント、エールポイント）の値を用いてよいし、仲間のユーザのユーザＩＤに対応付けられた選手数、仲間の数あるいは選手カードの能力値などを用いてもよい。 ゲームサーバ２０のＣＰＵ２１は、ログデータを参照して所定期間内にアクセスしている仲間のユーザを抽出する。ＣＰＵ２１は、抽出された仲間のユーザのユーザＩＤに対応付けられた技能レベルが所定の閾値以上の場合には、例えば、走者キャラクタＲＣを１〜３塁のそれぞれに配置してもよい。このようにして、得点チャンスや得点数が増える可能性のある出塁状況が設定されてもよい。また、複数の仲間のユーザが抽出された場合には、ＣＰＵ２１は、抽出された各ユーザのユーザＩＤに対応付けられた技能レベルの合計が所定の閾値以上の場合に、例えば、走者キャラクタＲＣを１〜３塁のそれぞれに配置してもよい。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。

例えば、上述した実施形態では、走者キャラクタＲＣの出塁状況が設定される場合について説明したが、これに限られない。例えば、設定手段５３は、打者に向かって飛んでくるボールの状況を設定してもよい。この場合、設定手段５３は、打者に向かってくるボールの色によって、打撃結果（ゲーム上の結果）が異なるように状況を設定してもよい。例えば、ボールの色が白である場合には、空振り又は単打としてもよく、ボールの色が赤である場合には、単打又は２塁打としてもよく、ボールの色が黄色である場合には、２塁打又は３塁打としてもよく、ボールの色が金色である場合には、本塁打としてもよい。ＣＰＵ２１は、例えば所定の確率、あるいはランダムにボールの色を設定してもよい。また、ＣＰＵ２１は、ボールの色と打撃イベントに基づき、ランダムあるいは所定の規則性に則って打撃結果（空振り、単打、２塁打、３塁打又は本塁打）を決定してもよい。

また、設定手段５３は、サッカーゲームのＰＫ戦において、ゴールに向かって飛んでくるボールを止める状況を設定してもよい。ここで、止めたボールの色によって獲得ポイント（ゲーム上の結果）が変わるように構成されてもよい。

また、上述した実施形態では、打撃イベントが繰り返して行われる場合を例として説明したが、打撃イベントを１回のみ行うようにしてもよい。

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

例えば、上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、設定手段５３、イベント発生手段５４、結果発生手段５５、取得手段５７、算出手段５８の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。通信端末１０は、ゲーム終了時には、ゲームの結果についてのデータをゲームサーバ２０へ送信し、ゲームサーバ２０は、受信したゲームの結果のデータをユーザと関連付けてゲームデータベース３２に記録するようにしてもよい。

１０…通信端末 １１…ＣＰＵ １２…ＲＯＭ １３…ＲＡＭ １４…画像処理部 １５…指示入力部 １６…表示部 １７…無線通信インタフェース部 １８…バス ２０…ゲームサーバ ２１…ＣＰＵ ２２…ＲＯＭ ２３…ＲＡＭ ２４…データベースアクセス部 ２５…通信インタフェース部 ２６…バス ３０…データベースサーバ ３１…ユーザデータベース ３２…ゲームデータベース ５１…登録手段 ５２…ゲーム進行手段 ５３…設定手段 ５４…イベント発生手段 ５５…結果発生手段 ５６…特典付与手段 ５７…取得手段 ５８…算出手段

Claims (12)

1. 現実世界の競技又は遊技を模擬したゲームを実行するゲーム制御装置であって、 前記ゲーム上のイベントに先立って、前記競技又は遊技で実現可能な状況を設定する設定手段と、 前記設定手段によって設定された状況の下で、所定の操作入力に関する情報に基づいて、前記イベントを発生させるイベント発生手段と、 前記設定手段によって設定された状況と、前記イベント発生手段によって発生した前記イベントに基づき、前記ゲーム上の結果を発生させる結果発生手段と、 を備えた、ゲーム制御装置。
2. ユーザ同士を関係付ける関係付け手段と、 ユーザからのアクセスに関する情報を取得する取得手段と、 前記取得手段が取得したアクセスに関する情報に基づいて、前記ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしているユーザ数を算出する算出手段とを備え、 前記設定手段は、前記ユーザ数の値が大きいほど、前記第１のユーザの前記ゲーム上の結果が有利になるように、前記状況を設定することを特徴とする、 請求項１に記載されたゲーム制御装置。
3. 前記設定手段は、前記イベントが２回以上連続して発生する場合には、２回目以降の前記イベントに先立って前記状況を設定するときに、前記ユーザ数に代えて、前記ユーザ数からイベント毎に値を減らしたユーザ数に基づいて、前記状況を設定することを特徴とする、 請求項２に記載されたゲーム制御装置。
4. ユーザ同士を関係付ける関係付け手段と、 ユーザからのアクセスに関する情報を取得する取得手段とを備え、 前記設定手段は、前記取得手段が取得したアクセスに関する情報に基づいて、前記ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしている第２のユーザが抽出された場合に、前記第１のユーザと前記第２のユーザとの前記ゲーム上の関係度合を示す親密度が高いほど、前記第１のユーザの前記ゲーム上の結果が有利になるように、前記状況を設定することを特徴とする、 請求項１〜３のいずれかに記載されたゲーム制御装置。
5. 野球を模擬したゲームを実行するゲーム制御装置であって、 前記ゲーム上の打撃イベントに先立って、走者キャラクタの出塁状況を設定する設定手段と、 前記設定手段によって設定された出塁状況の下で、所定の操作入力に関する情報に基づいて、前記打撃イベントを発生させるイベント発生手段と、 前記設定手段によって設定された出塁状況と、前記イベント発生手段によって発生した前記打撃イベントに基づき、前記ゲーム上の結果を発生させる結果発生手段と、 を備えた、ゲーム制御装置。
6. ユーザ同士を関係付ける関係付け手段と、 ユーザからのアクセスに関する情報を取得する取得手段とを備え、 前記設定手段は、前記取得手段が取得したアクセスに関する情報に基づいて、前記ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしている第２のユーザが抽出された場合に、前記第２のユーザと前記走者キャラクタとを対応付けた状態で前記走者キャラクタの出塁状況を設定することを特徴とする、 請求項５に記載されたゲーム制御装置。
7. 前記設定手段は、前記走者キャラクタが少なくとも一つの塁に存在する出塁状況が設定される場合に、前記第１のユーザと前記第２のユーザとの前記ゲーム上の関係度合を示す親密度が高いほど、前記第２のユーザに対応する走者キャラクタが、進塁する上で本塁に近い塁に配置されるように、出塁状況を設定することを特徴とする、 請求項６に記載されたゲーム制御装置。
8. ユーザ同士を関係付ける関係付け手段と、 ユーザからのアクセスに関する情報を取得する取得手段とを備え、 前記設定手段は、前記取得手段が取得したアクセスに関する情報に基づいて、前記ゲームを実行中の第１のユーザと関係付けられ、かつ所定期間内にアクセスしている第２のユーザが抽出された場合に、前記第２のユーザに対応付けられた所定の値の合計が大きいほど、前記第１のユーザの前記ゲーム上の結果が有利になるように、前記状況を設定することを特徴とする、 請求項１に記載されたゲーム制御装置。
9. 現実世界の競技又は遊技を模擬したゲームを実行するゲーム制御装置におけるゲーム制御方法であって、 前記ゲーム上のイベントに先立って、前記競技又は遊技で実現可能な状況を設定するステップと、 設定された状況の下で、所定の操作入力に関する情報に基づいて、前記イベントを発生させるステップと、 設定された状況と、発生した前記イベントに基づき、前記ゲーム上の結果を発生させるステップと、 を備えた、ゲーム制御方法。
10. 現実世界の競技又は遊技を模擬したゲームの実行を制御するために、コンピュータに、 前記ゲーム上のイベントに先立って、前記競技又は遊技で実現可能な状況を設定する機能、 設定された状況の下で、所定の操作入力に関する情報に基づいて、前記イベントを発生させる機能、及び 設定された状況と、発生した前記イベントに基づき、前記ゲーム上の結果を発生させる機能、 を実現させるためのプログラム。
11. 通信端末と、当該通信端末からアクセスされ、前記通信端末によるゲームの実行を制御するゲーム制御装置と、を含み、現実世界の競技又は遊技を模擬したゲームを実行するゲームシステムであって、 前記ゲーム上のイベントに先立って、前記競技又は遊技で実現可能な状況を設定する設定手段と、 前記設定手段によって設定された状況の下で、所定の操作入力に関する情報に基づいて、前記イベントを発生させるイベント発生手段と、 前記設定手段によって設定された状況と、前記イベント発生手段によって発生した前記イベントに基づき、前記ゲーム上の結果を発生させる結果発生手段と、 を備えた、ゲームシステム。
12. 現実世界の競技又は遊技を模擬したゲームの実行を制御するゲーム制御装置にアクセス可能な通信端末であって、 前記ゲーム上のイベントに先立って、前記競技又は遊技で実現可能な状況を示す情報を前記ゲーム制御装置から受信する受信手段と、 前記受信手段が受信した情報に示された状況の下で、所定の操作入力に関する情報に基づいて、前記イベントを発生させるイベント発生手段と、 前記情報に示された状況と、前記イベント発生手段によって発生した前記イベントに基づき、前記ゲーム上の結果を発生させる結果発生手段と、 を備えた、通信端末。

Images