以下、本発明の第1実施形態について説明する。
(1−1)ゲームシステムの構成 図1は、第1実施形態のゲームシステムのシステム構成例を示している。図1に示すように、このゲームシステムは、例えばインターネットなどの通信網NW(ネットワーク)に接続可能な通信端末10a,10b,10c,…と、通信網NWに接続されているゲームサーバ20と、データベースサーバ30とによって構成されている。各通信端末10a,10b,10c,…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、PDA(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機(いわゆる多機能型のスマートテレビも含む。)などの通信端末である。なお、以下の説明において、各通信端末10a,10b,10c,…に共通して言及するときには、通信端末10と表記する。 このゲームシステムにおいて、ゲームサーバ20は、クライアントである通信端末10と通信可能に構成されており、通信端末10に対してゲーミングサービスを提供する。ゲームサーバ20には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ30は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ20と例えば有線で接続される。 通信端末10は、ゲームサーバ20によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末10をウェブページ上で操作してゲームを実行する。
また、図1には図示していないが、ゲームサーバ20とは別に各通信端末10のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末10からのアクセスを受け入れるために複数のゲームサーバ20を設ける場合は、その複数のゲームサーバ20間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ20は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。
(1−2)通信端末の構成 図2及び図3を参照して通信端末10について説明する。 図2は、通信端末10の外観の例を示す図であって、(a)は、例えば折り畳み式の携帯端末(携帯電話機)などの釦入力方式の通信端末を例示したものであり、(b)は、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図3は、通信端末10の内部構成を示すブロック図である。 図3に示すように、通信端末10は、CPU(Central Processing Unit)11、ROM(Read Only Memory)12、RAM(Random Access Memory)13、画像処理部14、指示入力部15、表示部16、及び
、無線通信インタフェース部17を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス18が設けられている。
CPU11は、ROM12内のウェブブラウザをRAM13にロードして実行する。そして、CPU11は、指示入力部15等によってユーザに入力されるURL(Uniform Resource Locator)の適切な指定に基づき、無線通信インタフェース部17を介して、ゲームサーバ20からウェブページを表示するためのデータ、すなわち、HTML(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ(以下、総称して適宜「HTMLデータ」と表記する。)を、無線通信インタフェース部17を介して取得し、そのHTMLデータを解釈する。なお、通信端末10には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。 なお、HTMLデータの取得に当たって、CPU11は、予め登録されたユーザID(ユーザ識別情報)、あるいは指示入力部15を介して入力されるユーザIDを含むアクセス要求メッセージを、無線通信インタフェース部17を介してゲームサーバ20へ通知する。
ウェブブラウザは、画像処理部14を介して、取得したHTMLデータに基づき、ゲームサーバ20から提供されるウェブページを表示部16に表示する。また、ウェブブラウザは、ユーザが指示入力部15の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、その選択に応じたウェブページを表示するための新たなHTMLデータの送信(つまり、ウェブページの更新)をゲームサーバ20へ要求する。
画像処理部14は、HTMLデータの解析結果としてCPU11から与えられる表示用画像データに基づいて、表示部16にウェブページを表示する。表示部16は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むLCD(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面16aに表示する。
通信端末10が釦入力方式の通信端末(図2(a)に示す)である場合、指示入力部15は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群15a、及び、テンキーなどの複数の指示入力釦を含む釦群15bを備え、各釦の押下(操作)入力を認識してCPU11へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部16に表示されているウェブページをスクロールして表示することをCPU11へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示(例えば強調表示)されている1つのハイパーリンクまたはメニューをユーザが選択することをCPU11へ指示するために設けられる。なお、通信端末10を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末10を片手で保持したままその親指で操作(クリック)しやすいように、通信端末10の前面に配置されていることが好ましい。図2(a)に示す例では、釦群15bは、釦群15aの下方に配置され、「0」〜「9」、「*」、「#」(テンキー)が表記された複数の指示入力釦を含む。
通信端末10がタッチパネル入力方式の通信端末(図2(b)に示す)である場合、指示入力部15は、主として表示画面16aに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図2(b)に示すように、通信端末10がタッチパネル入力方式の場合であっても釦群15aが設けられる場合もある。
通信端末10に表示されるウェブページ上のメニューの選択操作は、例えば通信端末10が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末10がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面16a上のメニューの位置を指あるいはペンで指示(タッチ操作)することによって行われる。
(1−3)ゲームサーバの構成 図4を参照してゲームサーバ20の構成について説明する。 ゲームサーバ20は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末10に対してゲームのウェブサービスを提供する。図4に示すように、ゲームサーバ20は、CPU21、ROM22、RAM23、データベース(DB)アクセス部24、及び、無線通信インタフェース部25を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス26が設けられている。なお、ゲームサーバ20は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。
ROM22には、クライアントである通信端末10のウェブブラウザに対してHTML文書や画像などのオブジェクトの表示(ウェブページの表示)のサービスを提供するアプリケーションプログラムが格納されている。ROM22には、アプリケーションプログラム以外にもCPU21によって参照される各種データが格納されている。 CPU21は、ROM22内のゲームプログラムをRAM23にロードして実行し、無線通信インタフェース部25を介して、各種の処理を行う。
例えば、CPU21は、無線通信インタフェース部25を介して、HTMLデータを通信端末10宛に送信する。なお、ゲームサーバ20が通信端末10のユーザの認証処理を行う場合には、CPU21はその認証処理を行う。 CPU21は、通信端末10で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなHTMLデータの送信、または、ゲームサーバ20内の演算処理あるいはデータ処理などを含む。 データベースアクセス部24は、CPU21がデータベースサーバ30に対してデータの読み書きを行うときのインタフェースである。
(1−4)データベースサーバの構成 データベースサーバ30は、大容量のハードディスク装置やRAID(Redundant Arrays of Inexpensive Disks)等の形態の装置等、汎用ストレージで実現できる。データベースサーバ30内の各データベースは、ゲームサーバ20のデータベースアクセス部24を介してCPU21からのデータの読み書きが可能となるように構成されている。 図5に、データベースサーバ30の構成の一例を示す。図5に示すように、データベースサーバ30は、ユーザデータベース31と、ゲームデータベース32とを備える。
本実施形態のゲームサーバ20によって実行されるゲームは、現実世界の競技又は遊技を模擬したゲームであれば特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲームサーバ20によって実現されるゲームの一例として、野球形式のデジタルカードゲームを採り上げる。 野球形式のデジタルカードゲームは、ユーザが野球選手に対応する選手カードを収集することによって自らのチームを作り上げ、他のユーザのチームと野球の対戦する、あるいは技能レベルごとの野球のリーグ戦を戦うように構成されているゲームである。野球形式のデジタルカードゲームには、自らのチームを作り上げていくために選手カードを探索するスカウト処理や、抽選によって選手カードを入手することを可能とする抽選処理、あるいは2枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる強化処理等が設けられている。 野球形式のデジタルカードゲームに実装されている各機能については、後述する。
図6に、上述した野球形式のデジタルカードゲームにおいて適用されるユーザデータベース31の一例を示す。この例では、ユーザデータベース31は、ユーザID(ユーザ識別情報)ごとに、ユーザ名/表示画像、チーム、技能レベル、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、仲間のユーザID、保有カードの画像データ、及び保有カードのパラメータの各項目についての情報を含む。ユーザデータベース31に含まれる情報は、ゲームサーバ20によって逐次更新されうる。
以下の説明では、ユーザデータベース31に含まれるユーザID、あるいはユーザを特定するユーザ名(後述する)ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。・ユーザ名/表示画像 ゲームの実行時に通信端末10にユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ20によって提供されるネットワーク環境(あるいはゲームコミュニティ)上でユーザを特定する名称である。・チーム 上記野球形式のデジタルカードゲームにおいて、ユーザ登録時に、ユーザが指定するチームである。このゲームでは、例えば、P1〜P6の6チームからなるPリーグ、Q1〜Q6の6チームからなるQリーグが設けられており、ユーザはこの12チームの中からいずれかのチームをユーザ登録時に選択する。・技能レベル ゲーム上のユーザの技能レベル示すデータである。例えばLv1(レベル1)からLv100(レベル100)までの範囲のレベル値であり、例えばスカウトを継続的に行うことで順次技能レベルが上がるように構成される。・行動ポイント 上記野球形式のデジタルカードゲームにおいて、例えばユーザによるゲーム上のスカウトを行う上で必要となるポイントである。行動ポイントは、スカウトを行うことで低減し、所定の時間が経過する毎に回復(増加)する値である。・運営ポイント 上記野球形式のデジタルカードゲームにおいて、例えばユーザによるゲーム上の対戦を行う上で必要となるポイントである。運営ポイントは、他のユーザとの対戦等によって低減し、所定の時間が経過する毎に回復(増加)する値である。・強化ポイント 上記野球形式のデジタルカードゲームにおいて、例えばユーザによる選手カードの強化を行う上で必要となるポイントである。強化ポイントは、選手カードの強化を行うことで低減し、他のユーザとの対戦で勝利するか、あるいは所定の時間が経過する毎に回復(増加)する値である。・エールポイント 上記野球形式のデジタルカードゲームにおいて、仲間のユーザへ応援メッセージを送信することでユーザが取得するポイントである。・選手数 ユーザが保有する選手カードの数である。選手数は、スカウト処理や強化処理の実行によって増減する。選手数の最大値(例えば、60)は予め規定されている。・仲間のユーザID 対象とするユーザIDの仲間である他のユーザIDのデータである。・保有カードの画像データ 上記野球形式のデジタルカードゲームの場合、保有カードの画像データは、ユーザが保有する選手カードについての画像を含むデータである。・保有カードのパラメータ 保有カードのパラメータには、選手カードの能力値を示すデータが含まれる。例えば、図6に示すように、パラメータの項目として「打力」,「走力」,「守備力」等の各々の各能力値が含まれてもよい。図6の例では、能力値は0〜1000の範囲の値であって、能力値が大きい値であるほど能力が高いことを示している。図6では、能力の指標としての項目として、「打力」,「走力」,「守備力」を例示しているが、選手が投手であれば別の項目、例えば「球速」,「制球力」,「スタミナ」等としてもよい。
図5に戻り、ゲームデータベース32は、ゲームサーバ20からのアクセスに基づき、ゲームサーバ20によって実行されるゲームの設定についての情報や、ゲームの結果(ゲーム結果)に関する情報を記憶、更新する。ゲーム結果に関する情報は、ゲームの性質によって多様な情報
を含みうる。野球形式のデジタルカードゲームの場合を例に挙げれば、ゲーム結果に関する情報は、異なるユーザID同士の対戦の結果(スコア等)、特定の技能レベルの複数のユーザIDの間のリーグ戦の結果(スコア、ランキング等)、後述するミッション処理における得点結果などを含む。
(1−5)本実施形態のゲーム 以下、本実施形態のゲームに設けられている複数の処理のうちミッション処理について、具体的なゲームの流れを図7〜8を参照して説明する。図7は、本実施形態のゲームにおいて通信端末10に表示されるトップページの一例を示す図である。図8は、ミッション処理において通信端末10に表示されるウェブページの一例を示す図である。
図7に示すトップページは、個々のユーザIDに応じたウェブページで構成される。図7に例示されるトップページは、ユーザデータ表示領域、選手画像表示領域、メニュー表示領域を含む。 ユーザデータ表示領域は、対象となるユーザIDのユーザデータに含まれる、ユーザ名、クラブ、技能レベル(レベル)、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、仲間の各項目のデータ(図6参照)が表示される領域である。 選手画像表示領域は、対象となるユーザIDのユーザデータに含まれる複数の選手カードのうちユーザによって予め指定された選手カードの画像が表示される領域である。 メニュー表示領域は、本実施形態のゲームに設けられる複数の処理(スカウト処理、強化処理、試合処理、抽選処理、オーダー処理、ミッション処理)に対応した基本メニューとして、「スカウト」、「強化」、「試合」、「抽選」、「オーダー」、「ミッション」の各メニューm1〜m6が表示される領域である。つまり、ゲームで実行される複数の処理が各々割り当てられた複数のメニューが、通信端末10に表示されるウェブページの所定の位置にそれぞれ配置される。なお、メニューm5に対応するオーダー処理は、ユーザの操作に応じて、選手カードのオーダー(例えば打順や守備位置等)の入れ替え、先発オーダーに設定された選手カードと控えの選手カードとの交替等を行う処理である。
本実施形態のゲームのミッション処理は、ユーザが打撃イベントを繰り返す間に獲得した得点の合計が、スリーアウトになる前に所定値(例えば10点)以上に達した場合に特典を得る、というものである。本実施形態では、1回の打撃イベントの結果が1球で決まることとし、1回の打撃イベント毎にランナーの出塁状況が設定されるように構成されている。なお、特典が得られるための条件は任意に設定してよい。例えば、打撃イベントの結果が1回アウトになるまでに少なくとも1点を獲得すれば特典が得られるようにしてもよいし、スリーアウトになるまでに獲得した得点の合計が所定値以上に達した場合に特典が得られるようにしてもよい。また、付与される特典は、ゲーム上で任意に設定できる。例えば、特典は、一定量のエールポイントや強化ポイントなどであってもよいし、ゲーム内で入手するのが困難な選手カード(いわゆるレアカード)であってもよい。
本実施形態のゲームでは、図7に示すメニューm6の選択操作に応じて、図8に示すミッション処理が実行される。先ず、メニューm6の選択操作に応じて、図8(a)に示すようにウェブページが更新される。図8(a)に示すウェブページには、本塁と1〜3塁とを含むフィールドの画像が表示される領域と、現在のアウト数を色の変化により表す3つのマークと、現在の合計得点についての情報を表示するテキスト(図では現在の合計得点が0点であることを示す。)と、出塁するランナーの数(0〜3人のいずれか)を示すテキストが高速に切り替え表示される表示領域100と、出塁するランナーの数を決定するためのメニューm20などが含まれる。
図8(a)に示すウェブページにおいて、メニューm20が選択操作されると、表示領域100において高速に切り替え表示される数字(テキストに含まれる)の中からいずれかが決定される演出が行われ、出塁するランナーの数と、当該ランナーが配置される塁とが決定され、図8(b)に示すようにウェブページが更新される。なお、ランナーの数、塁を決定する演出としては、上記のようにテキストを高速に切り替え表示する場合の他に、例えば、ダイヤモンドを構成する塁上にランナーが1人いる状態、2人いる状態、満塁の状態あるいはランナーがいない状態のそれぞれの状態を示す画像やテキストを高速に切り替え表示し、このいずれか決定されるようにしてもよい。ここで、ランナーの数と、当該ランナーが配置される塁とは、メニューm20が選択操作されたタイミングに応じてランダムに決定されてもよいし、所定の規則性に基づいて決定されてもよい。図8(b)には、1人のランナー(走者キャラクタRC)が1塁に配置された場合のウェブページの表示例が示されている。なお、ランナーの出塁状況は、例えば「ワンアウトランナー3塁です。」等のように文字情報や音声情報等によってユーザが認識できるように構成されてもよい。また、図8(b)に示すウェブページには、打撃(バッティング)方法を選択することを促すメッセージと、バッティング方法として「ミート」を選択するためのメニューm21と、バッティング方法として「強振」を選択するためのメニューm22などが含まれる。この場合、例えば、ランナーが満塁の場合に、少ない点でも着実に得点を獲得するために「ミート」を選択するか、あるいは一度に大量得点を獲得するために「強振」を選択するかを、ユーザが選択できるように構成されている。 メニューm21またはメニューm22がユーザによって選択操作されると、選択されたバッティング方法による打撃イベントが行われ、当該打撃イベントの結果(ヒットまたはアウト)が、所定の、あるいはランダムな確率で決定される。また、打撃イベントの結果がヒットの場合には、ヒットの内容(単打、2塁打、3塁打あるいは本塁打)が、所定の、あるいはランダムな確率で決定される。
打撃イベントの結果がヒットの場合には、図8(c)に例示するウェブページに更新される。図8(c)には、ヒットの内容が3塁打であった場合のウェブページの表示例が示されている。図8(c)に示すウェブページには、ヒットの内容(図に示す例では3塁打)を示すテキスト等が表示される表示領域103と、ヒットの内容によって獲得した得点を示すテキスト(図に示す例では1点)の表示領域104などが含まれる。つまり、走者キャラクタRCが1塁に配置された状況において3塁打が出たことにより、獲得した得点は1点となる。獲得した得点は、合計得点に加算される。 ここで、獲得した合計得点が所定値以上に達すると、ユーザに対して特典が付与され、ミッション処理が終了する。また、獲得した合計得点が所定値未満の場合には、再度、図8(a)に例示するウェブページ上においてランナー数を決定する処理に移行する。ここで、再度ランナー数を決定する処理に移行する場合、それまでに獲得した合計得点と、アウト数とが保持される。
一方、打撃イベントの結果がアウトの場合には、アウト数が1つ加算され、図8(d)に例示するウェブページに更新される。図8(d)には、ノーアウトからワンアウトになった場合のウェブページの表示例が示されている。図8(d)に示すウェブページには、打撃イベントの結果(図に示す例ではアウト)を示すテキストの表示領域105などが含まれる。図8(d)に例示したウェブページでは、アウト数を表す3つのマークのうち一つのマークの色が変化した状態で表示されることにより、現在のアウト数を認識できるようになっている。 なお、アウト数が3(すなわちスリーアウト)に達すると、ミッション処理が終了する。また、アウト数が3未満の場合には、再度、図8(a)に例示するウェブページ上においてランナー数を決定する処理に移行する。ここで、再度ランナー数を決定する処理に移行する場合、それまでに獲得した合計得点と、アウト数とが保持される。
(1−6)ゲーム制御装置における各機能の概要 本実施形態では、ゲームサーバ20及びデータベースサーバ30によってゲーム制御装置が構成されている。以下では、上述した野球形式のデジタルカードゲーム(以下、適宜単に「ゲーム」という。)が適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図9を参照して説明する。図9は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。 なお、図9の機能ブロック図において、設定手段53、イベント発生手段54及び結果発生手段55が本発明の主要な構成に対応している。その他の手段は必ずしも必須の構成ではないが、本発明をさらに好ましくするための構成である。 なお、以下の説明において、通信端末10に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末10で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネルの操作によるウェブページのスクロール操作によって変化しうる。
登録手段51は、例えば通信端末10に提供するウェブページ上での通信端末10への適切な操作入力に基づいてユーザの要求を認識し、登録処理(ユーザ登録)を行う機能を備える。 登録手段51の機能は、例えば以下のとおり実現される。ゲームサーバ20のCPU21は、無線通信インタフェース部25を介して通信端末10から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ20から提供されるウェブページ上での通信端末10に対する所定の操作(例えば、所定のメニューの選択操作、テキスト入力等)によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末10を特定するための情報(例えばIPアドレス、メールアドレス等)が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザIDが含まれていてもよい。 CPU21は、登録要求メッセージを受信し、登録要求メッセージにユーザIDが含まれていない場合には、ユーザIDを新規に発行してそのユーザIDの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末10へ送信する。CPU21は、登録要求メッセージを受信し、登録要求メッセージにユーザIDが含まれている場合には、そのユーザIDの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末10へ送信する。 登録が完了すると、CPU21は、所定のデフォルトのデータが記述された新規のユーザIDについてのユーザデータを、ユーザデータベース31に格納する。
登録手段51はまた、ユーザIDに基づく申請を契機として当該ユーザIDを他のユーザIDと関係付けて登録してもよい。すなわち、登録手段51は、ユーザIDに基づく申請を契機として、他のユーザIDを「仲間」として登録する。なお、以下の説明では、ユーザIDが仲間の関係にあることと、対応するユーザが仲間の関係にあることとは、同義である。また、登録手段51は、本発明の「関係付け手段」の一例である。 この場合の登録手段51は例えば、以下のとおり実行される。ゲームサーバ20のCPU21は、無線通信インタフェース部25を介して、あるユーザIDに対応するユーザの通信端末10から、仲間になりたいユーザID(あるいは、対応するユーザ名)を指定した申請メッセージ(申請)を受け付ける。この申請メッセージの送信は、ユーザの通信端末10に提供されるウェブページの機能として予め設定されている。CPU21は、申請メッセージを受け付けると、申請メッセージに含まれるユーザIDに基づくアクセスがあったタイミングで、そのユーザIDに対応する通信端末10宛に、他のユーザIDに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示させるHTMLデータを送信する。そ
の申請を承認することが返信されれば、CPU21は、両者を仲間として登録する。具体的には、CPU21は、ユーザデータベース31内の対応する2つのユーザIDのユーザデータの「仲間」の箇所(図6参照)にデータを書き込む。
ゲーム進行手段52は、通信端末10に対するユーザの操作に応じて、通信端末10に表示されるウェブページを逐次更新するためのHTMLデータを送信することで、ゲームを進行させる。前述したように、野球形式のデジタルカードゲームには、ゲームを進行させる上で以下の処理が設けられている。・スカウト処理: 自らのチームを作り上げていくために選手カードを探索する処理である。スカウトを実行することで行動ポイントは消費するが、強化ポイントは増加する。・強化処理: 強化ポイントを消費することで、2枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる処理・試合処理: 他のユーザのチームと野球の試合を行う処理である。試合を行うことで運営ポイントは消費するが、試合に勝利すれば強化ポイントが増加する。・抽選処理: エールポイントを消費して、抽選によって選手カードを入手する処理である。・オーダー処理: ユーザが選手カードのオーダーの入れ替え、控えの選手カードとの交替等を実行するための処理である。・ミッション処理: 図8に関連して説明したように、ランナーの出塁状況に応じてバッティング方法を選択することにより、得点を獲得するための処理である。
なお、ゲーム進行手段52を実現するに当たり、ゲームサーバ20のCPU21は、ウェブページ上に表示される各メニューに、ゲームを進行させるためのいずれかの処理を予め割り当てている。そして、CPU21は、通信端末10においてウェブページ上のメニューが選択されたときに、選択されたメニューについての情報を通信端末10から受信し、受信した情報に基づいて、選択されたメニューに割り当てられた処理を実行する。
ゲーム進行手段52は、図7に示したように、ゲームで実行される複数の処理が各々割り当てられた複数のメニューを通信端末10に表示させる。具体的には、CPU21は、複数のメニューを含むウェブページを表示するためのHTMLデータを生成して通信端末10宛に送信する。上述したように、ゲームでは、スカウト処理、強化処理、試合処理及び抽選処理の各処理の実行に伴ってゲーム上のポイントが消費される。
例えば図7に示すトップページをユーザの通信端末10に表示する場合について、ゲーム進行手段52の機能は以下のようにして実現される。ゲームサーバ20のCPU21は、データベースアクセス部24を介してユーザデータベース31にアクセスし、ユーザデータ表示領域に含まれる各項目のデータと、選手画像表示領域に表示すべき選手カードの画像データを読み出す。次にCPU21は、図7に示したトップページが構成されるようにHTMLデータを生成し、通信端末10宛に送信する。生成されるHTMLデータは、ユーザごと(つまり、ユーザIDごと)に異なるものとなる。通信端末10は、受信したHTMLデータを解釈してトップページの画像を表示部16(表示画面16a)に表示する。
ゲーム進行手段52は、通信端末10に表示されたメニューに対するユーザの選択操作に応じて、それぞれスカウト処理、強化処理、試合処理、抽選処理及びミッション処理の各処理の実行を開始する。つまり、複数のメニューのいずれかを選択操作することによって、ゲームを構成する各処理の実行が開始される。好ましくは、各処理の実行が開始された場合、処理ごとに階層的に細分化された複数のメニューを含むようにしてウェブページが更新されつつ各処理が実行される。
[試合処理] ゲーム進行手段52は、他のユーザのチームと野球の対戦を行う試合処理を実行する機能を有する。
ゲーム進行手段52は、図10〜11を参照すると、例えば以下のとおり実現される。図10は、ゲーム進行手段52が試合処理を実行する機能を実現するために、主としてゲームサーバ20のCPU21によって実行される一連の処理を示すフローチャートである。図11は、ゲーム進行手段52の機能により実現される、ユーザの通信端末10上に表示されるウェブページの例を示す図である。
あるユーザIDに対応するユーザの通信端末10のトップページ上でメニューm3(図7参照)の選択操作がなされ、その選択結果を受信すると、ゲームサーバ20のCPU21は、そのユーザIDの対戦相手の複数の候補を、ユーザデータベース31に含まれる他のユーザIDの中からランダムに決定する。このとき、対戦するユーザの候補の技能レベルは、メニューm3を選択操作したユーザと同一の技能レベルであることが好ましい。CPU21は、複数の対戦相手の候補のリストからいずれかの候補を選択可能とするウェブページを表示するためのHTMLデータをユーザの通信端末10宛に送信する(ステップS10)。複数の対戦相手の候補のリストからいずれかの候補を選択する操作がユーザによってなされると(ステップS12:YES)、図11(a)に示すように、対戦相手ととともに試合開始の指示を促すメニューを含むウェブページが表示される。ここで、ユーザが「試合開始」のメニューを選択すると(ステップS14:YES)、CPU21は対戦結果を決定する処理を行う。対戦結果を決定するに当たって、CPU21は、データベースアクセス部24を介してデータベースサーバ30のユーザデータベース31にアクセスし、対象となるユーザIDの運営ポイントが試合の実行に必要とする所定量以上である場合に、運営ポイントからその所定量を減少させるとともに、対戦相手となる2つのユーザIDに対応付けられた複数の選手カードの能力を示すパラメータを読み出す。そして、CPU21は、読み出したパラメータに基づいてユーザ間の対戦結果を決定する(ステップS16)。なお、ステップS12において、対戦相手が選択されない場合(ステップS12:NO)には、CPU21は、ステップS12の処理を再度行う。また、ステップS14において、「試合開始」のメニューが選択されない場合(ステップS14:NO)には、CPU21は、ステップS12の処理を再度行う。
対戦結果の決定方法は、選手カードのパラメータがその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、対戦相手となる2人のユーザが保有する複数の選手カードのパラメータの合計値を比較し、合計値が大きな方のユーザが高い確率(例えば、60〜90%の範囲内の所定の確率)をもって勝利するように設定してもよい。この勝率は、パラメータの合計値の差が大きいほど高い確率としてもよい。このとき、図6に示したように、能力値を示すパラメータの項目が複数存在する場合には、各選手カードのパラメータを代表する値として、各項目のパラメータの値に対して所定の重み付け(例えば、図6の例では、「打力」を0.4、「走力」を0.2、「守備力」を0.4の重み付けにする等)をもって総合的な能力値を設定してもよい。
CPU21は、対戦結果を決定すると対戦結果をユーザに通知するために、その対戦結果を含むウェブページを表示させるHTMLデータを、「試合開始」のメニューの選択操作を行ったユーザの携帯端末10宛に送信する(ステップS18)。「試合開始」のメニューを選択する操作が行われてから、対戦結果を含むウェブページが表示されるまでの時間は極めて短時間(例えば数秒)であるため、ユーザは、簡易な操作のみで極めて短期間で対戦結果を知ることができる。図11(b)は、対戦処理の実行によって表示されるウェブページの一例を示す図である。図11(b)に例示したウェブページでは、例えばスコア等を含む試合結果が表示される。
[ミッション処理] 図8に関連して説明したように、ミッション処理は、ランナー(走者キャラクタRC)の出塁状況に応じてバッティング方法を選択することにより、得点を獲得していく処理である。ミッション処理は、設定手段53、イベント発生手段54、結果発生手段55及び特典付与手段56によって実行される。
設定手段53は、ゲーム上のイベントに先立って、現実世界の競技又は遊技で実現可能な状況を設定する機能を備える。ここで、「イベント」とは、ゲームにおいて模擬された現実世界の競技又は遊技において起こり得る事象であれば任意に選択することができる。例えば、本実施形態のゲームのように野球ゲームの場合には、イベントは、図8に例示した打撃イベントに限られず、投球あるいは走塁等のイベントであってよい。例えば、サッカーゲームの場合には、イベントは、ペナルティーキックのイベントであってもよいし、コーナーキックのイベントであってもよい。また、「競技又は遊技で実現可能な状況」とは、例えば、本実施形態のゲームのように野球ゲームの場合には、図8に例示したように塁上にランナーが配置されている状況に限られず、打者に向かってボールが飛んでくる状況であってもよい。なお、打撃イベントは、本発明の「イベント」の一例である。また、走者キャラクタRCの出塁状況は、本発明の「競技又は遊技で実現可能な状況」の一例である。 設定手段53の機能は、以下のようにして実現できる。ゲームサーバ20のCPU21は、図8(a)に示すウェブページを表示するためのHTMLデータを生成し、無線通信インタフェース部25を介して通信端末10宛に送信する。そして、図8(a)に示すウェブページ上でメニューm20が選択操作されると、CPU21は、ランナーの数と、当該ランナーが配置される塁とをランダムに決定する。なお、CPU21は、ランナーの数と、ランナーが配置される塁とを、所定の規則性に基づいて決定してもよい。CPU21は、ランナー(走者キャラクタRC)の数及び配置に基づいて、図8(b)に示すウェブページを表示するためのHTMLデータを生成し、通信端末10宛に送信する。
イベント発生手段54は、設定手段53によって設定された状況の下で、所定の操作入力に関する情報に基づいて、打撃イベント(イベント)を発生させる機能を備える。ここで、「所定の操作入力に関する情報」とは、例えば、ゲームサーバ20にアクセス可能な外部装置に対して所定の操作入力が行われたことを示す情報であってもよい。 イベント発生手段54の機能は、以下のようにして実現できる。ゲームサーバ20のCPU21は、図8(b)に示したウェブページ上でメニューm21あるいはメニューm22の何れかが選択操作されることにより、「ミート」に対応する打撃イベントと、「強振」に対応する打撃イベントの何れを発生させるかを判別する。
結果発生手段55は、設定手段53によって設定された状況と、イベント発生手段54によって発生した打撃イベント(イベント)に基づき、ゲーム上の結果を発生させる機能を備える。ここで、「ゲーム上の結果」とは、ゲーム全体の結果に限られず、ゲーム内の一部の局面における結果であってもよい。本実施形態の例では、「ゲーム上の結果」とは、1回の打撃イベントで獲得した得点であるが、例えば、打撃結果(ヒット又はアウト)であってもよいし、試合の対戦結果でもよい。また、本実施形態の例では、「状況」とは、走者キャラクタRCの出塁状況である。 結果発生手段55は、打撃イベントの結果(ヒット又はアウト)を判別する。打撃イベントの結果の判別方法については、図12に例示する判別用データに基づき判別してもよい。図12を参照し、判別用データについて説明する。図12(a)には、「ミート」に対応する打撃イベントが発生した場合の判別用データの一例が示されている。図12(b)には、「強振」に対応する打撃イベントが発生した場合の判別用データの一例が示されている。各判別用データは、1球目(1打席目)〜9球目(9打席目)の球数と、アウト数とに応じて、「ミート」あるいは「強振」の打撃イベントが発生したときにヒット又はアウトになる確率が設定
されている。例えば、ノーアウトで1球目に、「ミート」の打撃イベントが発生したときには、95%の確率でヒットとなる。一方、例えば、ノーアウトで1球目に、「強振」の打撃イベントが発生したときには、ヒットになる確率は70%である。なお、図12(a),(b)に記載された確率の値は例示であり、確率の値は適宜設定されうる。また、図12(a),(b)に例示された判別用データでは、9球目で必ずスリーアウトになるように設定されているが、球数は制限されなくてもよい。
また、結果発生手段55は、打撃イベントの結果をヒットと判別した場合に、当該打撃イベントのヒットの内容(単打、2塁打、3塁打あるいは本塁打のいずれか)を決定する。ヒットの内容は、打撃イベントに対応するバッティング方法毎に任意に設定されてもよい。例えば、「ミート」の打撃イベントの場合には、単打が65%、2塁打が20%、3塁打が10%、本塁打が5%の確率となるように決定されてもよい。また、「強打」の打撃イベントの場合には、例えば、単打が10%、2塁打が50%、3塁打が25%、本塁打が15%の確率となるように決定されてもよい。なお、これらの確率の値は、予めROM22に記録されてもよい。CPU21は、打撃イベントの結果をヒットと判別した場合、打撃イベントに対応するバッティング方法についてのヒットの内容を、ROM22に記録された確率の値に基づき決定する。
結果発生手段55は、走者キャラクタRCの出塁状況とヒットの内容とに基づいて、1回の打撃イベントでユーザが獲得した得点の値をもとめる。なお、走者キャラクタRCの出塁状況の全てのパターン毎に、ヒットの内容に応じて獲得される得点を示したテーブル情報が予めROM22に記録されていてもよい。具体的には、CPU21は、走者キャラクタRCの出塁状況とヒットの内容とを用いて、当該テーブル情報を参照することにより獲得される得点を求める。また、CPU21は、合計得点に対して、獲得された得点を加算する。なお、合計得点は、RAM23に記録されてもよい。
特典付与手段56は、結果発生手段56によって発生したゲーム上の結果に基づき、ユーザに対して特典を付与する機能を備える。本実施形態では、特典付与手段56は、ミッション処理において、スリーアウトになる前にユーザが獲得した合計得点の値が所定値(例えば10点)以上の場合に、当該ユーザに対して特典を付与する。なお、スリーアウトになるまでにユーザが獲得した合計得点の値に応じて、当該ユーザに付与される特典の内容が変動するようにしてもよい。例えば、ユーザが獲得した合計得点の値が大きいほど、ゲーム上、より高価な特典が付与されるようにしてもよい。特典の内容は特に問わないが、例えばゲーム上で利用可能なポイント(例えば、所定量のエールポイントや強化ポイント等)であってもよいし、ゲーム内で入手するのが困難な選手カード(いわゆるレアカード)であってもよい。 特典付与手段56の機能は、以下のようにして実現できる。なお、ユーザに対して付与する特典の内容については、予めROM22に記録されているものとする。CPU21は、1回のミッション処理が終了するまでにユーザが所定値以上の得点を獲得すると、ROM22を参照して、当該ユーザに対して特典を付与する処理を行う。なお、特典を付与する処理とは、付与対象となるユーザのユーザIDと、付与されるポイントやアイテムを関連付ける処理であってよい。例えば、特典として付与された強化ポイントをユーザに与える場合、CPU21は、付与対象となるユーザのユーザIDのユーザデータにおける強化ポイントを書き換える処理(与えられたポイントを加算する処理)を行ってよい。
(1−7)本実施形態のゲーム制御装置の主要な処理のフロー 次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図13のフローチャートを参照して説明する。図13のフローチャートは、主として設定手段53、イベント発生手段54、結果発生手段55及び特典付与手段56によって実行される処理である。
図7のウェブページ上でメニューm6が選択されたことを認識すると、ゲームサーバ20のCPU21は、図8(a)に示すウェブページを表示するためのHTMLデータを通信端末10宛に送信する。これにより、図8(a)に示すウェブページが通信端末10上に表示される(ステップS110)。次に、図8(a)に示すウェブページ上で「決定」メニューm20が選択されたことを認識すると(ステップS120:YES)、CPU21は、ランナー(走者キャラクタRC)の数及び配置を設定する(ステップS130)。そして、CPU21は、図8(b)に示すウェブページを表示するためのHTMLデータを通信端末10宛に送信する(ステップS140)。このとき、ユーザは、走者キャラクタRCの数及び配置に基づき、バッティング方法を自らの好みに応じて選択することが可能となる。
次に、図8(b)に示すウェブページ上で「ミート」メニューm21あるいは「強振」メニューm22が選択されたことを認識すると(ステップS150:YES)、CPU21は、図12に示した判別用データに基づいて、打撃結果(ヒット又はアウト)を決定する(ステップS160)。そして、打撃結果がヒットの場合には(ステップS170:YES)、CPU21は、ヒットの内容を決定する(ステップS180)。次に、CPU21は、ヒットの内容及び走者キャラクタRCの出塁状況に基づき、獲得した得点をもとめる(ステップS190)。CPU21は、ステップS180の処理において決定したヒットの内容と、ステップS190の処理においてもとめた得点とを含むウェブページを表示するためのHTMLデータを通信端末10宛に送信する(ステップS200)。そして、CPU21は、ステップS190の処理においてもとめた得点を合計得点に加算することにより、得点の合計を更新する(ステップS210)。次に、CPU21は、得点の合計が所定値(例えば10点)以上に達すると(ステップS220:YES)、ユーザに得点を付与する(ステップS230)。なお、ステップS220の処理において、得点の合計が所定値未満の場合には、CPU21は、ステップS110の処理に移行する。
上記ステップS170の処理において、打撃結果がアウトの場合には、CPU21は、RAM23に記憶されているアウト数を1つ増加する(ステップS240)。次に、CPU21は、図8(d)に示すウェブページを表示するためのHTMLデータを通信端末10宛に送信する(ステップS250)。そして、アウト数が3に達すると(ステップS260:YES)、CPU21は、ミッション処理を終了する。なお、ステップS260の処理において、アウト数が3未満の場合には、CPU21は、ステップS110の処理に移行する。
上述したように、第1実施形態のゲーム制御装置によれば、設定された出塁状況の下で、所定の操作入力に関する情報に基づいて打撃イベントが発生すると、設定された出塁状況と打撃イベントとに基づき得点を獲得することができる。これにより、得点の値は、単に、操作入力に関する情報に基づいて決定されるのではなく、打撃イベントに先立って設定された出塁状況によっても影響を受けることになる。このため、得点を獲得するまでの過程に対してもユーザに関心を持たせることができる。したがって、従来のゲームの課題である、結果のみがわかればよいといった単調なゲーム性を解消することができ、ゲームの興趣性を高めることができる。 例えば、本実施形態のゲームのように野球ゲームの場合には、打者による打撃のイベントに先立ち設定される状況として、塁上にランナーが何人いるか、というケースをとり得る。この場合、ランナーが多いほど得点チャンスや得点数が増える可能性があるため、ユーザはこの設定状況に関心を持つことになり、得点の値が決定されるまでの経過にも興味を持つことになる。
(2)第2実施形態 以下、本発明の第2実施形態について説明する。 第1実施形態では、走者キャラクタRCの出塁状況がランダムに設定されていたのに対し、第2実施形態では、走者キャラクタRCの出塁状況が、ゲームを実行中のユーザの仲間数に基づいて設定される点において異なる。 以下、第1実施形態と異なる構成について説明する。
第2実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図を図14に示す。図14に示す機能ブロック図は、図9に示したものと比較して取得手段57及び算出手段58が追加された点で異なる。
取得手段57は、ユーザからのアクセスに関する情報を取得する機能を備える。なお、「アクセス」には、パスワードや個体識別番号等、認証に必要な情報を携帯端末10から送信してアクセスする場合(ログインの場合)や、ログイン後にゲーム上の操作入力に関する情報を送信してウェブページの更新を要求する場合(例えばHTTPリクエストを送信する場合)などが含まれる。
取得手段57の機能は以下のようにして実現できる。ゲームサーバ20のCPU21は、ユーザIDに基づくアクセスがある度に、そのアクセスに関する情報をゲームデータベース32内のログデータに記録する。図15にログデータの構成例を示す。図15に示すように、ログデータは、ユーザID、アクセスの時刻の情報が、アクセスがあった時刻の順に記述されたデータである。例えば、CPU21は、図7に示すトップページを表示するためのHTMLデータの送信要求を受信したときに、ユーザID及びアクセスの時刻の情報をログデータに記録してもよいし、図7に示すトップページのメニューm6が選択操作されたことを認識したときにユーザID及びアクセスの時刻の情報をログデータに記録してもよい。 算出手段58は、取得手段57が取得したアクセスに関する情報に基づいて、ゲームを実行中のユーザ(第1のユーザ)と仲間の関係にあって、かつ所定期間内にアクセスしているユーザ数を算出する機能を備える。ここで、所定期間の起算点については2通りの方法を採ることができる。1つの方法は、プレイ中のユーザがログインした時刻を基準として、その時刻(基準時刻という。)の所定時間内にアクセスしている仲間のユーザの数を算出する方法である。もう1つの方法は、プレイ中のユーザがゲーム上の操作入力を行うことによりアクセスが行われた時刻を基準にして、その時刻(基準時刻という。)の所定時間内にアクセスしている仲間のユーザの数を算出する方法である。後者の方法はアクセスする度にユーザ数を算出することになるためCPU21の負荷が掛かるが、算出されるユーザ数の精度が高くなる。つまり、ユーザは、ログインしてから集中的にアクセスを行うとは限らないため、ログインの時刻を基準とするよりもユーザ数の算出精度が高くなる。
算出手段58の機能は、以下の通り実現することができる。ゲームサーバ20のCPU21は、ゲームデータベース32にアクセスしてログデータを参照して、対象となるユーザのログイン時刻を基準として所定時間内にアクセスしている仲間のユーザ数を算出する。あるいは、CPU21は、対象となるユーザからアクセスがある度に、ゲームデータベース32にアクセスしてログデータを参照して、対象となるユーザからアクセスしている時刻を基準として所定時間内にアクセスしている仲間のユーザ数を算出する。なお、CPU21は、仲間のユーザを判別するために対象となるユーザのユーザデータを参照する。
本実施形態では、設定手段53は、算出手段58によって算出されたユーザ数の値が大きいほど、ゲームを実行中のユーザ(第1のユーザ)のゲーム上の結果が有利になるように、状況を設定する機能を備える。ここで、「ゲーム上の結果が有利になるように、状況を設定する」とは、例えば、「ゲーム上の結果」を得点としたとき、ランナーが満塁の状況になるように設定することであってもよいし、2塁または3塁にランナー
を配置することであってもよい。また、設定手段53は、図16に例示する状況設定データに基づいて出塁状況を設定してもよい。図16に例示する状況設定データは、ゲームデータベース32に記憶されており、ログインしている仲間の数と、その数に対応するランナー(走者キャラクタRC)の数及び配置とを含む。図16に例示する状況設定データでは、ログインしている仲間の数が多くなるほど、ゲームを実行中のユーザが高得点を獲得しやすくなるように走者キャラクタRCが配置される。 設定手段53の機能は、以下のようにして実現できる。ゲームサーバ20のCPU21は、図8(a)に示すウェブページを表示するためのHTMLデータを生成し、無線通信インタフェース部25を介して通信端末10宛に送信する。そして、図8(a)に示すウェブページ上でメニューm20が選択操作されると、CPU21は、図16に例示する状況設定データに基づいて、ランナーの数と、当該ランナーが配置される塁とを決定する。なお、CPU21は、ランナーの数と、ランナーが配置される塁とを、所定の規則性に基づいて決定してもよい。CPU21は、図8(b)に示すウェブページを表示するためのHTMLデータを生成し、通信端末10宛に送信する。
次に、本実施形態のゲーム制御装置の処理のフローの一例について、図17のフローチャートを参照して説明する。なお、図17のフローチャートは、図13に示したフローチャートと異なる部分を説明するフローチャートであり、図13と共通する部分については同じ符号を用いている。図17のフローチャートは、主として設定手段53及び算出手段58によって実行される処理である。
まず、図8(a)に示すウェブページ上で「決定」メニューm20が選択されたことを認識すると(ステップS120:YES)、CPU21は、図15に示したログデータを参照して、ゲームを実行中のユーザの仲間のユーザのうち所定時間内にアクセスしているユーザ数を算出する(ステップS131)。次に、CPU21は、図16に示した状況設定データを参照し、走者キャラクタRCの数及び配置を設定する(ステップS132)。そして、CPU21は、図8(b)に示すウェブページを表示するためのHTMLデータを通信端末10宛に送信する(ステップS140)。以降の処理は、図13のフローチャートと同様である。
上述したように、第2実施形態のゲーム制御装置によれば、第1実施形態のゲーム制御装置の効果に加え、ゲームを実行中のユーザ(第1のユーザ)と関係付けられ、かつ所定期間内にアクセスしている仲間のユーザ数の値が大きいほど、ユーザは、より有利なゲーム上の結果を得ることができる。このため、第1のユーザには、より有利なゲーム上の結果を得るために、仲間のユーザと同時にアクセスすることが動機付けられる。すなわち、ゲームへのアクセスを多くすれば互いのメリットが向上することを仲間同士で認識しているため、ゲーム全体のアクセス数の向上に自然に寄与でき、この結果、ゲームのコミュニティの活性化、ソーシャル性を高めることができる。また、上記メリットを得るために、ユーザが仲間に対して、ゲーム内のチャットやメール、その他の手段でアクセスを呼びかけることも想定されるので、よりゲームのコミュニティの活性化を図ることができる。
(3)変形例 (3−1)変形例1 上記第2実施形態において、設定手段53は、打撃イベントが2回以上連続して発生する場合には、2回目以降の打撃イベントに先立って走者キャラクタRCの出塁状況を設定するときに、仲間のユーザ数に代えて、仲間のユーザ数から打撃イベント毎に値を減らしたユーザ数に基づいて、前記出塁状況を設定してもよい。 例えば、打撃イベントが繰り返し行われる毎に、同じユーザ数に基づいて出塁状況が設定される場合には、ユーザ数の値が大きければ、高得点を得ることの可能な出塁状況が常に設定されることから、仲間の数が多いユーザが突出して有利になってしまい、全体的なゲームのバランスが偏ってしまう可能性がある。一方、本変形例のゲーム制御装置によれば、打撃イベントの経過に従って、仲間のユーザ数を低減させていき、この低減された数に基づいて、出塁状況の設定が行われるので、上記のようなバランスの偏りを抑制することができる。
本変形例における設定手段53の機能は、以下のようにして実現される。ゲームサーバ20のCPU21は、図17に示したフローのステップS131の処理において算出した仲間のユーザ数をRAM23に記憶する。ここで、CPU21は、例えば、2回目以降の打撃イベントでは打撃イベント毎にRAM23に記憶されたユーザ数を1つずつ減らしていくようにしてもよい。この場合、1回目の打撃イベントにおいて算出された仲間のユーザ数が5人であった場合、図16に示した状況設定データを参照すると、走者キャラクタRCは1〜3塁にそれぞれ配置される。次いで、2回目の打撃イベントでは、RAM23に記憶されているユーザ数は1つ減少して4人になっているので、走者キャラクタRCは2塁及び3塁に配置されることになる。これにより、ランナーの数が1人減ったため、1回目の打撃イベントと比較して高得点が得られ難い状況となる。
(3−2)変形例2 上記第2実施形態において、設定手段53は、取得手段54が取得したアクセスに関する情報に基づいて、ゲームを実行中のユーザと関係付けられ、かつ所定期間内にアクセスしている仲間のユーザが抽出された場合に、前記ユーザと前記仲間のユーザとのゲーム上の関係度合を示す親密度が高いほど、前記ユーザの前記ゲーム上の結果が有利になるように、走者キャラクタRCの出塁状況を設定してもよい。
ここで、親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものである。親密度のデータ(親密度データ)の一例を図18に示す。図18に示す親密度データの例では、各ユーザの仲間のユーザ(ユーザID)と対応付けて、ユーザ間の応援メッセージの送信あるいは受信の頻度(応援頻度)、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数(プレゼント回数)などが記録され、これらの頻度や回数に基づいて一定の基準で親密度の値が設定される。応援頻度やプレゼント回数が多いほど親密度が高く設定される。また、一定の基準では、親密度の設定の基礎となる項目(図18では、応援頻度やプレゼント回数など)ごとに、重み付けを考慮したものであってもよい。例えば、応援頻度が少なくてもプレゼント回数が多い場合に親密度を高く設定してもよい。このような親密度データは、例えば、ユーザデータベース31内に記録される。
これにより、ゲームを実行中のユーザと、仲間のユーザとの親密度が高いほど、ゲームを実行中のユーザは、より有利なゲーム上の結果を得ることができる。例えば、野球ゲームの場合、打者による打撃のイベントに先立ち設定される状況として、ランナーをどの塁に配置するか、というケースをとり得るが、この場合、上記親密度が高いほど、1塁よりは2塁、3塁にランナーを配置する、というようにすればよい。このため、ユーザには、より有利なゲーム上の結果を得るために、親密度の高いユーザと同時にアクセスすることが動機付けられ、そのユーザとさらに関係性が高くなるような仕組みとすることができる。
設定手段53の機能は、以下のようにして実現される。ゲームサーバ20のCPU21は、ユーザデータベース31内のユーザデータと親密度データをユーザIDごとに紐付けて管理している。CPU21は、例えば応援メッセージの送受信やプレゼントの仲間の間での送受信を、無線通信インタフェース部25を介して送信先のユーザの要請に基づいて行っている。このような送受信が生ずると、CPU21は、対象となる親密度データを逐次更新する。 また、設定手段53は、プレイ中のユーザとの間の親密度が所定の閾値よりも高いユーザを抽出すると、例えば、走者キャラクタRCが1〜3塁の全てに配置されるように出塁状況を設定してもよいし、走者キャラクタRCが2塁及び3塁に配置されるように出塁状況を設定してもよい。
(3−3)変形例3 上記第2実施形態において、設定手段53は、取得手段57が取得したアクセスに関する情報に基づいて、ゲームを実行中の第1のユーザと関係付けられ、かつ所定期間内にアクセスしている第2のユーザが抽出された場合に、前記第2のユーザと走者キャラクタRCとを対応付けた状態で走者キャラクタRCの出塁状況を設定してもよい。 これにより、ゲームを実行中のユーザ(第1のユーザ)とほぼ同時にゲームをプレイしている仲間のユーザ(第2のユーザ)を走者キャラクタRCに見立てた状態で打撃イベントが行われるので、ゲームを実行中のユーザにとっては、仲間のユーザとともに野球の試合を行っているような感覚が得られる。このため、ユーザが、仲間のユーザとの関係度合いを高めることを動機付けることができる。
この場合、CPU21は、ログデータを参照して所定期間内にアクセスしている仲間のユーザを抽出し、抽出した仲間のユーザのユーザIDと走者キャラクタRCとを対応付ければよい。なお、CPU21は、例えば、図19に示すように、走者キャラクタRC1,RC2のそれぞれの近傍に仲間のユーザの表示名を表示する領域200,201を設けたウェブページを通信端末10上に表示させてもよい。
(3−4)変形例4 上記第2実施形態において、設定手段53は、走者キャラクタRCが少なくとも一つの塁に存在する出塁状況が設定される場合に、ゲームを実行中のユーザ(第1のユーザ)と当該ユーザの仲間のユーザ(第2のユーザ)との親密度が高いほど、仲間のユーザに対応する走者キャラクタRCが、進塁する上で本塁に近い塁に配置されるように、出塁状況を設定してもよい。 これにより、ユーザが、関係度合いの高い仲間のユーザを本塁に生還させるために、集中して打撃イベントをプレイすることを動機付けることができる。 本変形例の設定手段53では、CPU21は、走者キャラクタRCを少なくとも一つの塁に存在する出塁状況を設定する場合、走者キャラクタRCが存在する塁のうち、進塁する上で本塁に近い塁(3塁、2塁、1塁の順)に配置された走者キャラクタRCに対して、親密度の高い仲間のユーザを対応付ければよい。
(3−5)変形例5 上記第2実施形態において、設定手段53は、取得手段57が取得したアクセスに関する情報に基づいて、ゲームを実行中のユーザ(第1のユーザ)と関係付けられ、かつ所定期間内にアクセスしている仲間のユーザ(第2のユーザ)が抽出された場合に、前記仲間のユーザに対応付けられた所定の値の合計が大きいほど、ゲームを実行中のユーザのゲーム上の結果が有利になるように、出塁状況を設定してもよい。なお、ここで、第2のユーザが1人という場合もあるが、この場合の所定の値も上記合計に相当するものとする。 ここで、「仲間のユーザに対応付けられた所定の値」とは、例えば、仲間のユーザのゲーム上の能力の高さやゲーム上における進行レベルや到達ステージ等を示すレベルであってもよいし、仲間のユーザがゲーム上保有しているキャラクタやアイテム等の能力値、あるいは所定のポイント値などであってもよい。 このゲーム制御装置によれば、ゲームを実行中のユーザの仲間のうち所定期間内にアクセスしている仲間のユーザに対応付けられた値の合計が大きいほど、ゲームを実行中のユーザは、より有利なゲーム上の結果を得ることができる。このため、ゲームを実行中のユーザには、より有利なゲーム上の結果を得るために、仲間のユーザと同時にアクセスすることが動機付けられる。すなわち、ゲームへのアクセスを多くすれば互いのメリットが向上することを仲間同士で認識しているため、ゲーム全体のアクセス数の向上に自然に寄与でき、この結果、ゲームのコミュニティの活性化、ソーシャル性を高めることができる。また、上記メリットを得るために、ユーザが仲間に対して、ゲーム内のチャ
ットやメール、その他の手段でアクセスを呼びかけることも想定されるので、よりゲームのコミュニティの活性化を図ることができる。
本変形例における設定手段53の機能は、以下のようにして実現される。なお、以下の説明では、「仲間のユーザに対応付けられた所定の値」の一例として、仲間のユーザのユーザIDに対応付けられた技能レベルを用いているが、例えば、仲間のユーザのユーザIDに対応付けられた各種ポイント(行動ポイント、運営ポイント、強化ポイント、エールポイント)の値を用いてよいし、仲間のユーザのユーザIDに対応付けられた選手数、仲間の数あるいは選手カードの能力値などを用いてもよい。 ゲームサーバ20のCPU21は、ログデータを参照して所定期間内にアクセスしている仲間のユーザを抽出する。CPU21は、抽出された仲間のユーザのユーザIDに対応付けられた技能レベルが所定の閾値以上の場合には、例えば、走者キャラクタRCを1〜3塁のそれぞれに配置してもよい。このようにして、得点チャンスや得点数が増える可能性のある出塁状況が設定されてもよい。また、複数の仲間のユーザが抽出された場合には、CPU21は、抽出された各ユーザのユーザIDに対応付けられた技能レベルの合計が所定の閾値以上の場合に、例えば、走者キャラクタRCを1〜3塁のそれぞれに配置してもよい。
以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。
例えば、上述した実施形態では、走者キャラクタRCの出塁状況が設定される場合について説明したが、これに限られない。例えば、設定手段53は、打者に向かって飛んでくるボールの状況を設定してもよい。この場合、設定手段53は、打者に向かってくるボールの色によって、打撃結果(ゲーム上の結果)が異なるように状況を設定してもよい。例えば、ボールの色が白である場合には、空振り又は単打としてもよく、ボールの色が赤である場合には、単打又は2塁打としてもよく、ボールの色が黄色である場合には、2塁打又は3塁打としてもよく、ボールの色が金色である場合には、本塁打としてもよい。CPU21は、例えば所定の確率、あるいはランダムにボールの色を設定してもよい。また、CPU21は、ボールの色と打撃イベントに基づき、ランダムあるいは所定の規則性に則って打撃結果(空振り、単打、2塁打、3塁打又は本塁打)を決定してもよい。
また、設定手段53は、サッカーゲームのPK戦において、ゴールに向かって飛んでくるボールを止める状況を設定してもよい。ここで、止めたボールの色によって獲得ポイント(ゲーム上の結果)が変わるように構成されてもよい。
また、上述した実施形態では、打撃イベントが繰り返して行われる場合を例として説明したが、打撃イベントを1回のみ行うようにしてもよい。
上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。
例えば、上述した実施形態では、ネットワーク上のゲームサーバ20及びデータベースサーバ30によって、設定手段53、イベント発生手段54、結果発生手段55、取得手段57、算出手段58の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末10によって実現する構成としてもよいし、少なくとも一部の手段を通信端末10によって実現する構成としてもよい。通信端末10とゲームサーバ20とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末10によっても各機能を実現できる。通信端末10は、ゲーム終了時には、ゲームの結果についてのデータをゲームサーバ20へ送信し、ゲームサーバ20は、受信したゲームの結果のデータをユーザと関連付けてゲームデータベース32に記録するようにしてもよい。