コンピュータシステムおよびプログラム
【課題】オブジェクトに付与されたＩＤの使用登録によってゲーム内で使えるキャラクタを管理するゲームにおいて、重複するキャラクタとなるＩＤでもゲームで利用できるようにする。
【解決手段】同じ選手が対応づけられるオブジェクトを重複登録可能とするとともに、重複登録されたオブジェクトの選手の能力を初期状態から高める特典を付与する。
【解決手段】同じ選手が対応づけられるオブジェクトを重複登録可能とするとともに、重複登録されたオブジェクトの選手の能力を初期状態から高める特典を付与する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、チーム対戦のゲームを実行するための各プレーヤチームの所属選手を管理するコンピュータシステムおよびプログラムに関する。
【背景技術】
【０００２】
チーム対戦型ゲームのジャンルに、プレーヤがチームオーナの立場になって選手を集め、集めた選手の中から自分のチームを編成し、他プレーヤのチームと自動的に試合する様子を観戦するシミュレーションタイプのゲームが知られている。例えば、野球ゲームに関して非特許文献１に開示されている。
【０００３】
この種のジャンルのゲームでは、プレーヤは保有する選手の中から先発選手であるスタメン（スターティングメンバー）を９人選択するなどの編成をする。そして、プレーヤは、自分が編成したチームがどれだけ強いかを他プレーヤとの試合を通じて競って楽しむ。試合中は、各選手の行動はもちろん選手交代やどういった戦術で戦うかも自動で行われるため、プレーヤが試合前の準備で如何に試合状況を予測して編成をするかが腕のみせどころとなる。
【０００４】
また、この種のジャンルのゲームでは、選手集めをトレーディングカードの収集により行わせるものもある。このトレーディングカードには、それぞれゲーム内で使用できる選手が対応づけられており、プレーヤが所定のウェブサイト等でトレーディングカードの使用登録手続きをすることで自チームの編成に使える選手を登録することができる。こうしたゲームは、例えば、非特許文献２に開示されている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】株式会社セガ製オンラインゲーム「プロ野球チームをつくろう！ＯＮＬＩＮＥ２」、[online]、２００８年５月２７日運用開始、インターネット＜ＵＲＬ：http://www.yakyutsuku-online.com/＞
【非特許文献２】株式会社バンダイ製オンラインゲーム「プロ野球オーナーズリーグ」、［online］、２０１０年３月９日β版公開開始、２０１０年３月２０日カード販売開始、インターネット＜ＵＲＬ：http://ownersleague.jp/＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
市販されるトレーディングカードは、通常は中身が見えないようにパッケージされて販売される。その為、プレーヤがトレーディングカードを購入して集めようとすると同じ種類のカードを複数所有することが起きる。
【０００７】
一方、非特許文献２で開示されるゲームに限らず、オブジェクトの使用登録によってゲーム内で使えるキャラクタを管理するゲームでは、同じキャラクタを複数使用できないルールが適用される場合がある。例えば、非特許文献２に開示されたように現実のスポーツを仮想させる設定の場合、トレーディングカードに対応するのは選手であるから、同一選手が複数登場するのはゲームの主旨から外れると見なされるためである。
しかし、プレーヤの心情としては、せっかくオブジェクトを集めたのに同じ種類のオブジェクトがあってもそのうちの１枚しか使えないことになるので、少なからず損した気分となる。ここで、オブジェクトとは、実在のトレーディングカードやフィギュア等の玩具に限られず、仮想的なもの（トレーディングカードや玩具等のデータ）であってもよい。
【０００８】
本発明は、上述した課題に鑑みて為されたものであり、その目的とするところは、オブジェクトに付与されたＩＤの使用登録によってゲーム内で使えるキャラクタを管理するゲームにおいて、重複するキャラクタとなるＩＤでもゲームで利用できるようにして、オブジェクトのコレクションにおける重複所有に伴うネガティブな印象を軽減することである。
【課題を解決するための手段】
【０００９】
以上の課題を解決するための第１の形態は、チーム対戦のゲームを実行するための各プレーヤチームの所属選手を管理するコンピュータシステムであって、
複数の選手それぞれに対応づけて、当該選手に関するオブジェクトを記憶する記憶手段（例えば、図９のサーバ記憶部５０２、図１１のカード登録データ５１８）と、
プレーヤ端末からの操作入力に従って前記オブジェクトＩＤの使用登録要求を受け付ける受付手段（例えば、図９の通信部３７２、サーバ処理部２０２、ゲーム管理部２２０、図３０のステップＳ１０〜Ｓ１２）と、
前記受付手段により受け付けられたオブジェクトＩＤが、既に登録済みであった場合には使用登録を不許可とし、未登録であった場合には使用登録を許可として、各オブジェクトＩＤの使用登録の有無を管理する登録管理手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、カード登録処理部２２２、図１１のカード登録データ５１８、図３０のステップＳ１４〜Ｓ１６）と、
前記登録管理手段により使用登録されたオブジェクトＩＤに対応する選手を、プレーヤチームの所属選手とすることで、各プレーヤチームの所属選手を管理する所属選手管理手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、カード登録処理部２２２、図２６の選手登録リスト６１０、図３０のステップＳ２２）と、
各プレーヤチームについて、当該プレーヤチームの各所属選手について使用登録されたオブジェクトＩＤの使用登録の重複数に基づいて、当該プレーヤチームの所属選手のパラメータ、及び／又は、当該プレーヤチーム全体のパラメータを変更するパラメータ変更処理を実行するパラメータ変更手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、カード登録処理部２２２、チーム編成処理部２２４、図２６の選手登録リスト６１０、図３０のステップＳ３２〜Ｓ３４、図３２のステップＳ２１０）と、を備えたコンピュータシステムである。
【００１０】
また、コンピュータに、各プレーヤチームの所属選手を管理するチーム対戦のゲームを実行するためのプログラムであって、
複数の選手それぞれに対応づけて、当該選手に関するオブジェクトに付与されたオブジェクト固有のＩＤ（以下「オブジェクトＩＤ」という。）を記憶する記憶手段、
プレーヤ端末からの操作入力に従って前記オブジェクトＩＤの使用登録要求を受け付ける受付手段、
前記受付手段により受け付けられたオブジェクトＩＤが、既に登録済みであった場合には使用登録を不許可とし、未登録であった場合には使用登録を許可として、各オブジェクトＩＤの使用登録の有無を管理する登録管理手段、
前記登録管理手段により使用登録されたオブジェクトＩＤに対応する選手を、プレーヤチームの所属選手とすることで、各プレーヤチームの所属選手を管理する所属選手管理手段、
各プレーヤチームについて、当該プレーヤチームの各所属選手について使用登録されたオブジェクトＩＤの使用登録の重複数を用いて、当該プレーヤチームの所属選手のパラメータ、及び／又は、当該プレーヤチームの全体のパラメータを変更するパラメータ変更処理を実行するパラメータ変更手段、
として前記コンピュータを機能させるためのプログラムを構成することとしてもよい。
【００１１】
第１の形態によれば、オブジェクトはオブジェクトＩＤにより使用登録の可否が管理されるとともに、同一選手のオブジェクトについての重複登録をも管理される。そして、使用登録されたオブジェクトに対応する選手がチーム編成に使用可能となり、例えば重複登録された選手のパラメータやチームのパラメータが変更される。
よって、同一選手のオブジェクトを所有してもその内の１枚だけしかゲームで使えないのではなく、その他のオブジェクトもゲームに利用できるようになる。また、オブジェクトのコレクションにおける重複所有に伴うネガティブな印象を軽減するどころか、オブジェクトの重複登録により特典が付与されるというポジティブな作用効果を奏する。
【００１２】
第２の形態は、前記パラメータ変更手段は、当該所属選手についてのオブジェクトＩＤの使用登録の重複数が、当該所属選手に予め定められた重複登録数条件を満たした場合に、当該所属選手のパラメータを変更する第１の手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、カード登録処理部２２２、図２６の選手登録リスト６１０、図３０のステップＳ２８）を有する第１の形態のコンピュータシステムである。
【００１３】
第２の形態によれば、第１の形態と同様の効果を奏するとともに、同一選手のオブジェクトを重複登録した回数がある基準を満たすと特典が付与されるようになるので、同一選手のオブジェクトを重複所有することによるゲームの興趣を与えることができる。
【００１４】
第３の形態は、前記プレーヤ端末からの操作入力に従って、当該プレーヤチームの各所属選手のポジションを設定するポジション設定手段（例えば、図９の通信部３７２、サーバ処理部２０２、ゲーム管理部２２０、チーム編成処理部２２４、図２６の選手登録リスト６１０、図３１のステップＳ１２４〜Ｓ１５４）を更に備え、
前記パラメータ変更手段は、パラメータ変更の判定用として予め定められたポジション条件を満たすポジションに設定された所属選手についてのオブジェクトＩＤの使用登録の重複数に基づいて、当該所属選手のパラメータ、及び／又は、当該プレーヤチーム全体のパラメータを変更する第２の手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、チーム編成処理部２２４、図２６の選手登録リスト６１０、図３３のステップＳ１６２、Ｓ１６６〜Ｓ１７０）を有する、第１又は第２の形態のコンピュータシステムである。
【００１５】
第３の形態によれば、第１又は第２の形態と同様の効果を奏するとともに、重複登録された選手のポジションがある特定の条件を満たすと特典を付与するようにできる。よって、同一選手のオブジェクトを重複所有することによるゲームの興趣を与えることができる。
【００１６】
第４の形態は、前記スポーツゲームは野球ゲームであり、
前記第２の手段は、バッテリーを前記ポジション条件として、投手及び捕手に設定された所属選手についてのオブジェクトＩＤの使用登録の重複数に基づいて、当該所属選手のパラメータ、及び／又は、当該プレーヤチーム全体のパラメータを変更する第３の形態のコンピュータシステムである。
【００１７】
第４の形態は、第３の形態と同様の効果を奏するとともに、重複登録された選手が投手と捕手であるといった限定的な条件を満たす場合に、特典が付与されるようにできる。これによって、同一選手のオブジェクトを重複所有することによるゲームの興趣を与えることができる。
【００１８】
第５の形態は、各選手には、複数のパラメータ項目それぞれに対する標準パラメータ値が定められており、前記パラメータ変更手段は、相対的にパラメータ値が高いパラメータ項目のパラメータ値をより向上させて当該所属選手の特徴をより増長させるように前記パラメータ変更処理を行う第１〜第４の何れかの形態のコンピュータシステムである。
【００１９】
第５の形態によれば、第１〜第４の形態の何れかと同様の効果を奏するとともに、重複登録された選手の特徴が増長されるような特典を付与できる。よって、重複登録の特典をよりゲーム内で感じられるようにできる。
【００２０】
第６の形態は、前記オブジェクトには、同一選手であってもシリーズの異なるオブジェクトが有り、
前記記憶手段は、各選手の各シリーズ毎に、前記オブジェクトＩＤを対応付けて記憶し、
前記パラメータ変更手段は、各所属選手について重複使用登録されたオブジェクトＩＤのシリーズに基づいて前記パラメータ変更処理を実行する第３の手段を有する第１〜第５の何れかの形態のコンピュータシステムである。
【００２１】
第６の形態によれば、第１〜第５の形態の何れかと同様の効果を奏するとともに、同一選手であれば重複登録可能とすることで、重複所有されたオブジェクトの使い道をより多彩にしてより一層ゲームの興趣を高めることができる。
【００２２】
第７の形態は、前記オブジェクトには、監督オブジェクトが含まれており、前記登録管理手段により使用登録されたオブジェクトＩＤが監督カードのオブジェクトＩＤであった場合に、当該監督を当該プレーヤチームの監督に設定するチーム監督管理手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、カード登録処理部２２２、図１４の監督設定データ５４０、図２６の監督登録リスト６０８、図２９のステップＳ５０〜Ｓ５２）と、
各プレーヤチームについて、当該プレーヤチームの監督について使用登録されたオブジェクトＩＤの使用登録の重複数に基づいて、当該プレーヤチーム全体のパラメータを変更するチーム全体パラメータ変更手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、チーム編成処理部２２４、図３４のステップＳ２６０〜Ｓ２６２）と、を更に備えた第１〜第６の何れかの形態のコンピュータシステムである。
【００２３】
第７の形態によれば、第１〜第６の形態の何れかと同様の効果を奏するとともに、監督オブジェクトを重複登録した場合にも特典付与を与えることができるので、オブジェクトの重複所有をより一層ポジティブなものにするとともにゲームの興趣を高めることができる。
【００２４】
第８の形態は、前記ゲームの実行ルールとして前記パラメータ変更手段によるパラメータ変更の是非を設定するパラメータ変更ルール設定手段（例えば、図９のゲーム管理部２２０、リーグ作成処理部２３４、図１５のリーグ設定データ５５０、図３５のリーグ作成処理）を更に備えた、第１〜第７の何れかの形態のコンピュータシステムである。
【００２５】
第８の形態によれば、第１〜第７の形態の何れかと同様の効果を奏するとともに、オブジェクトの重複登録を利用してゲームの実行ルールに多様性を持たせることでゲームの興趣を高めることができる。
【００２６】
第９の形態は、前記所属選手管理手段は、使用登録されたオブジェクトＩＤに対応する選手の他に、前記プレーヤチームの所属選手として、前記オブジェクトＩＤの使用登録無しで事前に自動付与される事前付与選手を管理し、当該事前付与選手と当該使用登録されたオブジェクトＩＤに対応する選手とが同一選手であった場合に、当該事前付与選手を所属選手から除外する事前付与選手管理手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、チーム編成処理部２２４、）を有する、
第１〜第８の何れかの形態のコンピュータシステムである。
【００２７】
第９の形態によれば、例えば、プレーヤチームの構成人数に所属選手が不足する場合に、事前付与選手を自動付与するといった形態が可能となる。事前付与選手は、同一選手に係るオブジェクトＩＤが使用登録された場合には、所属選手から除外されることとなる。
【図面の簡単な説明】
【００２８】
【図１】ゲームシステムの構成例を示す図。
【図２】プレーヤ端末である携帯型ゲーム装置の構成例を説明するための外観図。
【図３】メニュー画面の表示の一例を示す図。
【図４】選手登録の表示の一例を示す図。
【図５】チーム編成画面の表示の一例を示す図。
【図６】リーグ作成画面の表示の一例を示す図。
【図７】参加リーグ設定画面の表示の一例を示す図。
【図８】試合シミュレーション画面の表示の一例を示す図。
【図９】プレーヤ端末である携帯型ゲーム装置と、サーバシステムとの機能構成の一例を示す機能ブロック図。
【図１０】ゲーム関連データのデータ構成の一例を示す図。
【図１１】カード登録データのデータ構成の一例を示す図。
【図１２】選手設定データのデータ構成の一例を示す図。
【図１３】個人戦術傾向パラメータのデータ構成の一例を示す図。
【図１４】監督設定データのデータ構成の一例を示す図。
【図１５】リーグ設定データのデータ構成の一例を示す図。
【図１６】リーグ参加チームリストのデータ構成の一例を示す図。
【図１７】投球パターンデータのデータ構成の一例を示す図。
【図１８】打撃パターンデータのデータ構成の一例を示す図。
【図１９】犠牲バント適当条件テーブルのデータ構成の一例を示す図。
【図２０】犠牲バント選択確率テーブルのデータ構成の一例を示す図。
【図２１】通常攻撃戦術選択確率テーブルのデータ構成の一例を示す図。
【図２２】敬遠選択条件テーブルのデータ構成の一例を示す図。
【図２３】奇襲警戒適当条件テーブルのデータ構成の一例を示す図。
【図２４】奇襲警戒選択確率テーブルのデータ構成の一例を示す図。
【図２５】通常守備戦術選択確率テーブルのデータ構成の一例を示す図。
【図２６】チーム設定データのデータ構成の一例を示す図。
【図２７】スタメンリストのデータ構成の一例を示す図。
【図２８】プレイデータのデータ構成の一例を示す図。
【図２９】サーバシステムにおける主たる処理の流れを説明するためのフローチャート。
【図３０】選手登録処理の流れを説明するためのフローチャート。
【図３１】チーム編成処理の流れを説明するためのフローチャート。
【図３２】図３１より続くフローチャート。
【図３３】指定重複登録処理の流れを説明するためのフローチャート。
【図３４】チームパラメータ変更処理の流れを説明するためのフローチャート。
【図３５】リーグ作成処理の流れを説明するためのフローチャート。
【図３６】試合シミュレーション処理の流れを説明するためのフローチャート。
【図３７】図３６より続くフローチャート。
【図３８】攻撃戦術決定処理の流れを説明するためのフローチャート。
【図３９】守備戦術決定処理の流れを説明するためのフローチャート。
【発明を実施するための形態】
【００２９】
〔第１実施形態〕
本発明を適用した第１実施形態としては、オブジェクトとしてトレーディングカードを用いて選手登録をするシミュレーションタイプの対戦野球ゲームを実行する例について説明する。
【００３０】
［ゲームシステムの構成］
図１は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態は、パソコン１２００や、スマートフォン１３００、携帯型ゲーム装置１４００と言ったプレーヤ端末が、通信回線１を介してコンピュータシステムであるサーバシステム１１００と接続し、ゲーム実行に必要なデータを送受し合うシステムで実現される。
【００３１】
通信回線１は、データ授受が可能な通信路を意味する。すなわち、通信回線１とは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。
【００３２】
サーバシステム１１００は、複数のブレードサーバ１１０２を備えた筐体１１０４と、ブレードサーバ１１０２の管理操作に用いるキーボード１１０６及びディスプレイモニタ１１０８とを備える。ブレードサーバ１１０２は、ＣＰＵやＩ／Ｏモジュール、ＩＣメモリ、ハードディスク等のストレージなどを備え、一台のサーバコンピュータとして機能する。筐体１１０４には、各ブレードサーバ１１０２や、それらに電力を供給する電源モジュール、通信回線１に接続するための通信装置等を搭載する。
【００３３】
そして、本実施形態におけるサーバシステム１１００は、例えばＣＧＩ（Common gateway interface）プログラム実装言語をシステムサポートし、プレーヤ登録手続きや、登録プレーヤの認証（所謂ログイン処理）、野球ゲーム、チャットなどのプレーヤ間のコミュニケーション、といった各種機能をＣＧＩの仕組みを利用して提供する。
【００３４】
尚、サーバシステム１１００は、単独のサーバコンピュータにより実現される構成であっても良いのは勿論である。或いは、据え置き型の家庭用ゲーム装置がサーバ装置としての機能を実現する構成であっても良い。
【００３５】
パソコン１２００や、スマートフォン１３００、携帯型ゲーム装置１４００は、いずれもゲーム画面表示プログラムを実行させることのできるコンピュータである。ゲーム画面表示プログラムとは、サーバシステム１１００から受信した表示情報に基づいて、各種画面を表示する機能や、操作入力に応じたリクエスト情報をサーバシステム１１００へ送信する機能を実現するためのプログラムである。
ゲーム画面表示プログラムは、サーバシステム１１００で生成される表示情報を専用のデータ形式とするならば専用のクライアントプログラムにより実現される。表示情報が、ＨＴＭＬやAdobe Flash（Adobeは登録商標）などを用いてインタラクティブに画像や音声を制御する形式とするならば、汎用のウェブブラウザのプログラムなどでも実現できる。
【００３６】
プレーヤ２は、本実施形態における野球ゲームをプレイするために、事前に野球選手や監督を想起させる意匠を有した専用のオブジェクト（トレーディングカード３）を購入する必要がある。オブジェクト（トレーディングカード３）は、所定枚数を１パッケージとして市販される。このパッケージは、内包されているオブジェクト（トレーディングカード３）の意匠が外からは認識できないようになっている。
【００３７】
オブジェクト（トレーディングカード３）そのものは、監督オブジェクト（監督カード３ａ）と、投手・捕手・野手を含む選手オブジェクト（選手カード３ｂ）との２種類から構成されている。そして、各々には固有の識別情報、オブジェクトＩＤが付与されている。本実施形態では、オブジェクトＩＤとしてオブジェクト番号が印刷されているものとするが、数字以外の文字列でも良いし、バーコードやＱＲコードなどにより実現しても良い。
【００３８】
また、オブジェクト（トレーディングカード３）は、実在の野球リーグの進行状況を反映するように、販売期間ごとに独自のシリーズ（例えば第１弾、第２弾といった各弾のこと。）を構成して供給される。つまり、最新のシリーズ（例えば第２弾）は、現実の野球リーグにおけるその時の出場選手を反映するようにオブジェクト（トレーディングカード３）の種類が編成される。当然、複数のシリーズ（例えば第１弾〜第２弾）に亘って同じ監督や同じ選手に対応するオブジェクト（トレーディングカード３）が含まれる場合もあり得るが、シリーズ違いで同一監督や同一選手のオブジェクト（トレーディングカード３）の意匠は、想起させる監督や選手は変更されないが、画法やポーズ、レイアウトなどに変化がつけられる。換言すると、同じ選手や監督を想起させるオブジェクト（トレーディングカード３）でも、シリーズ違いでモデル（型）が異なるのである。尚、同じ監督や同じ選手のオブジェクト（トレーディングカード３）であっても、シリーズ違いやモデル違いに係わらずに固有のカード番号が付与される点は変わらない。
【００３９】
プレーヤ２は、取得したオブジェクト（トレーディングカード３）を、プレーヤ端末を使って使用登録し、当該オブジェクト（カード）に対応する選手をゲーム内で使用可能にする。そして、使用可能にした選手を使って自分のチームを編成して他プレーヤのチームとリーグ戦を戦う野球ゲームを楽しむ。
【００４０】
［プレーヤ端末の構成］
次に、プレーヤ端末の代表として、携帯型ゲーム装置１４００の構成例について説明する。図２は、本実施形態におけるプレーヤ端末である携帯型ゲーム装置１４００の構成の一例を説明するための外観図である。
【００４１】
携帯型ゲーム装置１４００は、方向入力キー１４０２と、プッシュスイッチ１４０４と、第１液晶ディスプレイ１４０６と、第２液晶ディスプレイ１４０８と、スピーカ１４１０と、イメージセンサ１４３０と、制御ユニット１４５０とを、ヒンジ１４１４で開閉自在な折り畳み型の装置本体１４０１に備えている。そして、第１液晶ディスプレイ１４０６及び第２液晶ディスプレイ１４０８の表示面上には、スタイラスペン１４１６などで触れることによって表示画面の任意位置を接触入力することのできるタッチパネル１４０７、１４０９がそれぞれ装着されている。
【００４２】
また、装置本体１４０１には、コンピュータ読み出し可能な情報記憶媒体であるメモリカード１４４０からデータを読み込んだりデータを書き込みできるメモリカード読取装置１４１８が備えられている。メモリカード１４４０には、携帯型ゲーム装置１４００の制御ユニット１４５０がゲームプレイに係る各種演算処理を実行するために必要なプログラムや各種設定データが記憶されている。その他、装置本体１４０１には図示されていない内蔵バッテリーや電源ボタン、音量調節ボタン等が設けられている。
【００４３】
タッチパネル１４０７、１４０９は、表示画面を遮蔽することなくそれぞれ第１液晶ディスプレイ１４０６及び第２液晶ディスプレイ１４０８の表示画面のほぼ全域を被い、プレーヤがスタイラスペン１４１６（或いは指など）で触れる接触操作を行うと、左上を原点とする直交座標系における接触位置座標を制御ユニット１４５０へ出力することができる。
【００４４】
イメージセンサ１４３０は、ＣＣＤイメージセンサ（Charge Coupled Device Image Sensor）やＣＭＯＳイメージセンサ（Complementary Metal Oxide Semiconductor Image Sensor）などの撮像素子である。オブジェクト（トレーディングカード３）のオブジェクトＩＤ（カードＩＤ）をバーコードやＱＲコードで付与する構成では、これを読み取るための撮影に使用される。
【００４５】
制御ユニット１４５０は、ゲーム装置の制御基板に相当し、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ(Application Specific Integrated Circuit)、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリを搭載する。
【００４６】
また、制御ユニット１４５０は、無線通信モジュール１４１２や、第１液晶ディスプレイ１４０６及び第２液晶ディスプレイ１４０８のドライバ回路、タッチパネル１４０７及びタッチパネル１４０９のドライバ回路、方向入力キー１４０２及びプッシュスイッチ１４０４からの信号を受信する回路、スピーカ１４１０へ音声信号を出力するためのアンプ回路、メモリカード読取装置１４１８への信号入出力回路といった所謂Ｉ／Ｆ回路（インターフェース回路）を搭載する。これら制御ユニット１４５０に搭載されている各要素は、それぞれバス回路を介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。
【００４７】
そして制御ユニット１４５０は、メモリカード読取装置１４１８によってメモリカード１４４０に格納されているプログラムやデータを読み出して、搭載するＩＣメモリにこれらを一時記憶する。そして、読み出したプログラムを実行して演算処理を実行し、方向入力キー１４０２やプッシュスイッチ１４０４、タッチパネル１４０７及び１４０９からの操作入力に応じて携帯型ゲーム装置１４００の各部を制御する。
【００４８】
尚、本実施形態では、携帯型ゲーム装置１４００は必要なプログラムや各種設定データをメモリカード１４４０から読み出す構成としているが、制御ユニット１４５０に搭載されている主要なプログラムやデータをＩＣメモリに予め記憶している構成とすることができる。或いは、無線通信モジュール１４１２を介して、インターネットやＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などの有線／無線の通信回線１に接続し
て外部装置からダウンロードして取得する構成としても良い。
【００４９】
［ゲームの概要］
次に、図３〜図８を参照しながら、本実施形態における野球ゲームの概要について説明する。プレーヤは、先ずプレーヤ端末である携帯型ゲーム装置１４００を起動させて、ゲーム画面表示プログラムを実行させる。次いで、通信回線１を介してサーバシステム１１００に接続して所定のログイン手続きを済ませると、図３に示すようなメニュー画面Ｗ２が表示される。
【００５０】
本実施形態の携帯型ゲーム装置１４００はデュアルディスプレイなので、第１液晶ディスプレイ１４０６にタイトル表示部４とアカウント表示部６とが表示され、第２液晶ディスプレイ１４０８にメニュー選択アイコンが複数並ぶメニュー選択アイコン表示部８が表示される。プレーヤは、スタイラスペン１４１６で所望するメニュー選択アイコンをタッチして選択操作するか、方向入力キー１４０２とプッシュスイッチ１４０４を用いて何れかのアイコンを選択操作する。
【００５１】
本実施形態の野球ゲームを楽しむためには、プレーヤは自身が取得したオブジェクト（トレーディングカード３）を使用登録してゲーム内で使えるようにしなければならない。選手オブジェクト（選手カード３ｂ）の使用登録を、本明細書では「選手登録」と呼び、監督オブジェクト（監督カード３ａ）の使用登録を「監督登録」と呼ぶ。
【００５２】
メニュー選択アイコン表示部８から「選手登録」のアイコンを選択すると、当該操作に対応するリクエスト情報つまりオブジェクト（カード）の使用登録要求が、携帯型ゲーム装置１４００からサーバシステム１１００に送信される。サーバシステム１１００は、このリクエスト情報を受信して、携帯型ゲーム装置１４００に選手画面を表示させるための表示情報を返信する。以下同様に、携帯型ゲーム装置１４００で何らかの操作入力をすると、それに対応するリクエスト情報がサーバシステム１１００に送信され、これを受信したサーバシステム１１００が対応するゲーム管理処理を実行し、新たな表示情報を返信することを繰り返す。
【００５３】
図４は、本実施形態における選手登録画面Ｗ４の一例を示すゲーム画面図であり、同図の上側が上画面、下側が下画面を示す。以降の各画面を示す図面も同様である。
選手登録画面Ｗ４では、新規に登録するオブジェクト（カード）のオブジェクト（カード）番号を入力するオブジェクト（カード）番号入力欄１０と、オブジェクト（カード）番号を入力するためのソフトウェアキーボード１２と、入力されたオブジェクト（カード）に対応する選手についての説明文やパラメータ（能力）値などを表示する選手情報表示部１４と、登録済の選手の選手アイコンが表示される登録選手一覧１６と、操作案内表示１８とが表示される。
【００５４】
プレーヤが、オブジェクト（カード）番号入力欄１０へソフトウェアキーボード１２を使って使用登録したいと思うオブジェクト（トレーディングカード３）のオブジェクト（カード）番号を入力すると、当該オブジェクト（カード）に対応づけられている選手の情報がサーバシステム１１００から返信され、選手情報表示部１４にて表示される。プレーヤは、選手情報表示部１４の内容を確認して、この選手を登録したければ操作案内表示１８に従って所定の登録操作をする。所望するオブジェクト（トレーディングカード３）の登録を済ませ、メニュー画面に戻るメニュー復帰操作をすると、再びメニュー画面Ｗ２に戻ることができる。
【００５５】
選手情報表示部１４には、例えば選手アイコン１４ａや、背番号、選手名、守備位置や投打の左右設定、能力パラメータ値１４ｂ、選手説明文１４ｃ、同一選手重複登録数１４ｄ、特典付与状態マーク１４ｅが表示される。
【００５６】
本実施形態では、同一選手の同種のオブジェクト（トレーディングカード３）を重複して登録することができる。既に選手登録されている選手の元になったオブジェクト（トレーディングカード３）と今回新たに登録するオブジェクト（トレーディングカード３）とが同種である場合、つまり、２つのオブジェクト（トレーディングカード３）に対応付けられている選手が同じでのシリーズも同じである場合、自動的に重複登録扱いとなる。つまり、同じ選手が二人登録されるのではなく、既に登録されている選手に自動的に登録が纏められる。そして、同一選手重複登録数１４ｄは、同じ選手のオブジェクト（カード）を複数枚登録している場合にその合計数を示す。
尚、同じ選手に対応づけられるオブジェクト（トレーディングカード３）でも、シリーズが異なる場合（例えば第１弾と第２弾）、及び／又は、オブジェクト（トレーディングカード３）の意匠が異なる場合、それぞれ別選手として登録される。この例外的処置は、オブジェクト（トレーディングカード３）はシリーズ違いや意匠違いでコレクション性に価値が存在する点に配慮するためであり、必ずしもこれに限る物ではない。
【００５７】
そして、オブジェクト（トレーディングカード３）を重複登録すると、当該オブジェクト（カード）に対応する選手には特典が付与される。特典の内容はゲームの内容に応じて適宜設定可能である。特典付与状態マーク１４ｅは、その選手に特典付与が適用されていることを通知する。尚、本実施形態は野球ゲームなので、選手の競技パラメータが向上するように特典付与が行われるがこれに限らない。例えば、ＲＰＧ（role-playing game）の場合には、アイテムを付与したり、所持金を加算したり、ヒットポイントを回復させる、と言った具合に、ゲームで有利となるように適宜設定することができる。
【００５８】
一方、「監督登録」をするためには、メニュー画面Ｗ２のメニュー選択アイコン表示部８から「監督登録」を選択操作する。すると、選手登録と同様にして監督オブジェクト（監督カード３ａ）を登録し、チーム監督に就任させることができる。登録対象のオブジェクト（カード）と同種オブジェクト（カード）が既に使用登録されている場合には、選手登録と同様に重複登録される。
【００５９】
選手登録及び監督登録を行ったならば、プレーヤは使用可能に登録した選手の中からスタメン（スターティングメンバーの略）、交代要員、控え投手を編成して、自チームを編成する。チーム編成をするためには、メニュー画面Ｗ２のメニュー選択アイコン表示部８から「チーム編成」を選択操作する。
【００６０】
「チーム編成」を選択操作すると、携帯型ゲーム装置１４００では、例えば図５に示すようなチーム編成画面Ｗ６が表示される。チーム編成画面Ｗ６には、スタメンの編成用画面を切換表示させるためのスタメン編成タグ２０、交代要員の編成用画面を切換表示させるための交代要員編成タグ２２、控え投手の編成用画面を切換表示させるための控え投手編成タグ２４が表示される。プレーヤは、編成したい部門に応じたタグを選択する。
【００６１】
スタメン編成タグ２０を選択すると、スタメン設定状態表示部２６が表示される。同表示部では、グラウンドを俯瞰視した略図を背景にして、各守備ポジションに現在登録されている選手の選手アイコン３０が表示される。選手が未登録の守備ポジションについてはブランクのアイコン３２が表示される。
【００６２】
守備ポジションの選択は、スタメン設定状態表示部２６に表示された選手アイコン３０又はブランクアイコン３２をスタイラスペン１４１６によるタッチ操作、又は方向入力キー１４０２及びプッシュスイッチ１４０４を使って選択することで行う。そして、スタメン設定状態表示部２６で何れかのアイコンが選択操作されると、当該アイコンの守備ポジションンが設定対象ポジションとなり、当該守備ポジションに登録されている選手の情報が選手情報表示部３４に表示される。
【００６３】
プレーヤが、設定対象ポジションに既に登録されている選手を外したければ、操作案内表示３８に従って所定の「はずす」操作をする。また、設定対象ポジションに選手を新たに登録したければ、登録選手一覧３６から所望する選手の選手アイコンをタッチして選択する。或いは、登録選手一覧３６から選手アイコンを所望する守備ポジションン位置のアイコンへ、ドラック・アンド・ドロップ操作する。選手情報表示部３４に表示されている選手の打順は、打順指定欄３５で設定できる。
【００６４】
但し、同一選手だがオブジェクト（トレーディングカード３）のシリーズ違いで別々に登録された選手については、その同一選手が既に何れかの守備ポジションに登録されている場合には、登録できないように処理される。つまり、同じ人物が２人存在しないように扱われる。
【００６５】
その一方で、本実施形態では、スタメン設定状態表示部２６が表示された状態において、シリーズ違いのオブジェクト（トレーディングカード３）であるために別々に登録されている同一選手をプレーヤの意思でどれかに纏めて重複登録することができる。
具体的には、登録選手一覧３６の選手アイコンを、同一選手で既に何れかの守備ポジションに登録されている選手アイコン３０へドラック・アンド・ドロップ操作した場合、重複操作された元の選手をドロップ先の守備ポジションに登録されている選手に纏めることができる。つまり、重複操作された元の選手の選手登録が抹消される。但し、本実施形態では、重複操作先の選手、つまり登録が残された側の選手には、選手登録時と同様にして特典が付与される。
尚、スタメン設定状態表示部２６が表示された状態での別の重複操作としては、既に選手が登録されている守備ポジションを選択した状態で、重複操作に対応するボタン操作をしてから登録選手一覧３６の中から、先に選択しておいた守備ポジションに登録されているのと同一選手の選手アイコンを選択するといった方法が考えられる。
【００６６】
チームの編成が完了したならば、プレーヤは自分が編成したチームをどのリーグに参加させるかを決める。参加できるリーグは、自身で作る事もできるし、他プレーヤが既に作成してある中から選ぶこともできる。
【００６７】
メニュー画面Ｗ２のメニュー選択アイコン表示部８において、「リーグ作成」を選択すると、携帯型ゲーム装置１４００では、例えば図６に示すようなリーグ作成画面Ｗ１０が表示される。同画面には、リーグ名を設定するリーグＩＤ設定欄６０と、そのリーグに参加するために必要なパスワードを設定する参加パスワード設定欄６２と、リーグ名やパスワードの文字や数字を入力するためのソフトウェアキーボード６４と、レギュレーション設定部６６と、操作案内表示６８とが表示される。
【００６８】
レギュレーション設定部６６には、当該リーグにおけるレギュレーションの項目と、当該項目の設定内容をプルダウン形式で選択できる項目選択欄との組み合わせが複数表示される。レギュレーション設定部６６において、プレーヤは、リーグ名や参加パスワード、各種レギュレーションの内容を自由に設定できる。本実施形態では、レギュレーションの項目には、「重複登録」の許可／不許可の設定が含まれる。「重複登録」は、リーグ期間中における重複を許可するか否かを設定する。
【００６９】
リーグ名や参加パスワード、各種レギュレーションの内容を設定して、操作案内表示６８に従って所定の登録操作をすると、新しいリーグが登録される。尚、リーグ名とその参加パスワードは、別途、プレーヤが親しい友人に教えることで広めるものとする。つまり、親しい友人同士でリーグを組んでゲームを楽しむ事ができるのである。
【００７０】
メニュー画面Ｗ２のメニュー選択アイコン表示部８において「リーグ参加」を選択すると、携帯型ゲーム装置１４００では、例えば図７に示すような参加リーグ設定画面Ｗ１２が表示される。同画面には、参加を希望するリーグＩＤを入力するためのリーグＩＤ入力欄７０と、参加に必要なパスワードを入力する為のパスワード入力欄７２と、リーグＩＤやパスワードの文字や数字を入力するためのソフトウェアキーボード７４と、登録済のリーグの情報を表示するリーグ一覧表示７６と、操作案内表示７８とが表示される。
【００７１】
プレーヤは、参加希望するリーグ名（本実施形態におけるリーグＩＤ）を、リーグ一覧表示７６で表示されるリーグ名をタッチ操作するなどして選択するか、ソフトウェアキーボード７４を用いて入力する。そして、予め入手しておいたそのリーグの参加パスワードを、ソフトウェアキーボード７４を用いて入力し、操作案内表示７８に従って所定の登録操作をすると、プレーヤのチームが入力したリーグに参加登録される。
【００７２】
チーム編成と参加するリーグの登録を済ませると、プレーヤは自分のチームを他プレーヤのチームと試合させることができるようになる。
【００７３】
メニュー画面Ｗ２のメニュー選択アイコン表示部８において、「試合」を選択すると、サーバシステム１１００では当該プレーヤのチームと、同じリーグの他のチームとの試合のシミュレーション処理（試合の自動制御）が行われ、その結果が随時携帯型ゲーム装置１４００へ送信される。携帯型ゲーム装置１４００では、例えば図８に示すような試合シミュレーション画面Ｗ１４が表示される。
【００７４】
試合シミュレーション画面Ｗ１４には、スコアボード８０と、試合画面表示部８２と、カウント表示部８４と、進塁状況表示部８６と、操作案内表示８８とが表示される。
【００７５】
試合画面表示部８２は、試合の様子を示す画像を表示する。この試合画像は、サーバシステム１１００が試合のシミュレーションを実行して出した試合の進行状況を再現する画像である。試合画像を表示させるための表示情報の生成、及びその表示情報に基づく携帯型ゲーム装置１４００における試合画面の表示に関する処理は、公知のＣＧＩゲームにおけるゲームプレイの画面の表示と同様に実現できる。
プレーヤは、試合シミュレーション画面Ｗ１４で自分が編成したチームの試合ぶりを観戦し、同じリーグに参加する友人とチームの勝敗を競って楽しむ。
【００７６】
［機能ブロックの説明］
次に、本実施形態の機能構成について説明する。
図９は、本実施形態におけるプレーヤ端末である携帯型ゲーム装置１４００と、サーバシステム１１００との機能構成の一例を示す機能ブロック図である。
【００７７】
携帯型ゲーム装置１４００は、操作入力部１００と、処理部２００と、音出力部３５０と、画像表示部３６０と、通信部３７０と、記憶部５００とを備える。
【００７８】
操作入力部１００は、プレーヤによって為された各種の操作入力に応じて操作入力信号を処理部２００に出力する。例えば、プッシュスイッチや、ジョイスティック、タッチパッド、トラックボール、２軸以上の検出軸を有する多軸検出型加速度センサ又は検出軸方向を違えて組み合わされた単軸検出型加速度センサユニット、少なくとも２方向以上の検出方向を有する多方向検出型傾斜センサまたは検出方向を違えて組み合わされた単方向検出型傾斜センサユニット、などによって実現できる。図２の方向入力キー１４０２や、プッシュスイッチ１４０４、３軸加速度センサ１４２２はこれに該当する。
【００７９】
そして、操作入力部１００は、接触位置検出部１０４と撮像部１０６とを含む。
接触位置検出部１０４は、表示画面範囲への接触位置を検出することのできるデバイスで実現される。図２のタッチパネル１４０７，１４０９がこれに該当する。
撮像部１０６は、画像情報を取得する手段であって、例えばＣＣＤイメージセンサやＣＭＯＳイメージセンサによって実現される。図２のイメージセンサ１４３０がこれに当る。
【００８０】
処理部２００は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１００や記憶部５００を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００からの操作入力信号に基づいて各種の演算処理を実行して、携帯型ゲーム装置１４００の動作を制御する。図２の制御ユニット１４５０が処理部２００に該当する。そして、本実施形態における処理部２００は、ゲーム画面表示制御部２１０と、音生成部２５０と、画像生成部２６０と、通信制御部２７０とを備える。
【００８１】
ゲーム画面表示制御部２１０は、サーバシステム１１００から表示情報を受信して、メニュー画面Ｗ２や、選手登録画面Ｗ４、チーム編成画面Ｗ６、リーグ作成画面Ｗ１０、参加リーグ設定画面Ｗ１２及び試合シミュレーション画面Ｗ１４と言った各種ゲーム画面を表示させ、それらのゲーム画面において操作入力部１００へ為された操作に応じてリクエスト情報をサーバシステム１１００へ送信するための各種処理を実行する。
具体的には、ウェブブラウザをベースとして、ＨＴＭＬとともにＪａｖａ（登録商標）やＣＳＳ（Cascading Style Sheets）を利用して能動的に画面表示を制御するウェブ技術や、Adobe Flash（Adobeは登録商標）などの能動的なプラグインを用いて実現できるが、その他の方法でもかまわない。
【００８２】
音生成部２５０は、例えばデジタルシグナルプロセッサ（ＤＳＰ）や、音声合成ＩＣなどのプロセッサ、音声ファイルを再生可能なオーディオコーデック等によって実現され、ゲーム画面表示制御部２１０による処理結果に基づいてゲームに係る効果音やＢＧＭ、各種操作音の音信号を生成し、音出力部３５０に出力する。
【００８３】
音出力部３５０は、音生成部２５０から入力される音信号に基づいて効果音やＢＧＭ等を音出力する装置によって実現される。図２のスピーカ１４１０がこれに該当する。
【００８４】
画像生成部２６０は、例えば、ＧＰＵ、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、ビデオ信号ＩＣ、ビデオコーデックなどのプログラム、フレームバッファ等の描画フレーム用ＩＣメモリ等によって実現される。画像生成部２６０は、ゲーム画面表示制御部２１０による処理結果に基づいて１フレーム時間（例えば１／６０秒）で１枚のゲーム画面を生成し、生成したゲーム画面の画像信号を画像表示部３６０に出力する。
【００８５】
画像表示部３６０は、画像生成部２６０から入力される画像信号に基づいて各種ゲーム画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。
本実施形態では、図２の第１液晶ディスプレイ１４０６及び第２液晶ディスプレイ１４０８がこれに該当する。
【００８６】
通信制御部２７０は、データ通信に係るデータ処理を実行し、通信部３７０を介して外部装置とのデータのやりとりを実現する。
【００８７】
通信部３７０は、通信回線１と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現され、図２の無線通信モジュール１４１２がこれに該当する。
【００８８】
記憶部５００は、処理部２００に携帯型ゲーム装置１４００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームプレイに必要なプログラム、各種データ等を記憶する。また、処理部２００の作業領域として用いられ、処理部２００が各種プログラムに従って実行した演算結果や操作入力部１００から入力される入力データ等を一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図２の制御ユニット１４５０が搭載するＩＣメモリやメモリカード１４４０がこれに該当する。
【００８９】
本実施形態では、記憶部５００はシステムプログラム５０４と、ゲーム画面表示制御プログラム５０６とを記憶している。システムプログラム５０４は、携帯型ゲーム装置１４００のコンピュータとしての入出力の基本機能を実現するためのプログラムである。ゲーム画面表示制御プログラム５０６は、処理部２００が読み出して実行することによってゲーム画面表示制御部２１０としての機能を実現させるためのアプリケーションソフトであるが、システムプログラム５０４の一部として組み込まれた構成であっても良い。
【００９０】
本実施形態におけるサーバシステム１１００は、操作入力部１０２と、サーバ処理部２０２と、画像表示部３６２と、通信部３７２と、サーバ記憶部５０２とを備える。
【００９１】
操作入力部１０２は、サーバの管理のための各種操作を入力するための手段であり、携帯型ゲーム装置１４００の操作入力部１００と同様に実現される。図１のキーボード１１０６がこれに該当する。
【００９２】
サーバ処理部２０２は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１０２やサーバ記憶部５０２を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１０２からの操作入力信号に基づいて各種の演算処理を実行して、サーバシステム１１００の動作を統合的に制御する。そして、本実施形態では、ゲーム管理部２２０と、画像生成部２６２と、通信制御部２７２とを含む。
【００９３】
ゲーム管理部２２０は、各種ゲーム画面をプレーヤ端末で表示させるための表示情報の生成、野球シミュレーションゲームへ参加するプレーヤの情報管理、チームの設定情報の管理、シミュレーションに関する処理等を実行する。
より具体的には、ゲーム管理部２２０は、カード登録処理部２２２と、チーム編成処理部２２４と、チーム傾向決定部２２６と、戦術決定処理部２２８、ゲーム進行制御部２３０と、リーグ作成処理部２３４と、リーグ参加設定処理部２３６とを含む。
【００９４】
カード登録処理部２２２は、オブジェクト（トレーディングカード３（（監督カード３ａ及び選手カード３ｂ）））の使用登録に関する処理を実行し、プレーヤがオブジェクト（カード）に対応するキャラクタをゲーム中で使用可能にする。例えば、選手登録画面Ｗ４（図４参照）の表示情報の生成、オブジェクト（カード）番号の照合、使用登録の可否判定、新たに使用登録されたオブジェクト（カード）に対応する選手のリスト化などを行う。
【００９５】
チーム編成処理部２２４は、チーム編成画面Ｗ６（図５参照）をプレーヤ端末で表示させるための表示情報を生成し、チーム編成画面Ｗ６におけるプレーヤ端末での操作入力に従ってプレーヤのチームを編成する処理を実行する。すなわち、スタメン編成に関する処理と、交代要員編成に関する処理と、控え投手編成に関する処理とを実行する。
【００９６】
チーム傾向決定部２２６は、予め定められた戦術判断要素に関するチーム全体としての傾向を決定する。本実施形態では、所定のメンバー条件（スタメンに登録）を満たす選手の個人戦術傾向パラメータ５３０（図１３参照）に基づいてチーム全体の攻守それぞれの戦術選択傾向を示す「基礎攻撃戦術傾向パラメータ」と「基礎守備戦術傾向パラメータ」を算出する。
【００９７】
戦術決定処理部２２８は、対戦の自動制御を実現する機能部の一つであって、攻守それぞれにおける戦術をチーム全体の戦術判断要素に関する傾向に基づいて決定する。
具体的には、チーム全体の戦術判断要素に関する傾向（「基礎攻撃戦術傾向パラメータ」と「基礎守備戦術傾向パラメータ」）と、チームの主要キャラクタ（本実施形態では、投手、打者、監督。つまり場面場面の戦術選択に強く影響を与えるキャラクタ）に定められた傾向と、試合の進行状況とに基づいて、攻撃戦術および守備戦術を決定する。
【００９８】
より具体的には、攻撃または守備の基礎攻撃戦術パラメータに、その時の戦術決定に影響を与える選手（本実施形態では、投手、打者）の個人戦術傾向パラメータ５３０を加算して、「中間攻撃傾向パラメータ」「中間守備傾向パラメータ」を算出し、更に監督の個人戦術傾向パラメータ５３０を加算して、最終的に戦術選択時に供される戦術傾向パラメータ（「最終攻撃戦術傾向パラメータ」と「最終守備戦術傾向パラメータ」）を算出する。これらの戦術傾向パラメータは、ゲーム関連データ５１６に格納される。
【００９９】
ゲーム進行制御部２３０は、対戦の自動制御を実現する機能部の一つであって、主に野球の試合のシミュレーション処理を実行する。すなわち、プレーヤのチームを構成する選手、および他チームを構成する選手それぞれを所定のＡＩ制御で制御してそれぞれの行動を決定し、野球の試合をシミュレーションする。そして、シミュレーションした試合画像をプレーヤ端末で表示させるための表示情報を生成する。
【０１００】
チャット制御部２３２は、プレーヤ間でのコミュニケーション手段の１つとしてチャット機能を提供するための処理を実行する。
【０１０１】
リーグ作成処理部２３４は、プレーヤの操作入力に基づいて、対戦するチームを選択するための母集団の枠組みの作成に関する処理を実行する。具体的には、リーグの名称などのＩＤと、当該母集団へ参加するための条件（パスワードを含む）と、その母集団から選ばれたチームの対戦に適用されるレギュレーションとを設定するための処理を実行する。より具体的には、リーグ作成画面Ｗ１０の表示情報の生成、同画面における操作入力に基づいて、リーグ設定情報をサーバ記憶部５０２に記憶させる処理を行う。尚、対戦形式がリーグ方式ではなく、トーナメント方式の場合には、母集団はトーナメントとする。
【０１０２】
リーグ参加設定処理部２３６は、プレーヤが作成したチームをリーグ作成処理部２３４で作成された母集団へ参加させるための手続き処理を行う。具体的には、参加リーグ設定画面Ｗ１２（図７参照）をプレーヤ端末で表示させるための表示情報を生成し、同画面における操作入力に基づいて参加登録の処理をする。
【０１０３】
画像生成部２６２は、サーバシステム１１００の保守に関する画像を生成し、画像表示部３６２へ出力する。試合画面の表示情報として静止画や動画の情報を送信する場合に、それらを生成する機能を持たせても良い。
【０１０４】
画像表示部３６２は、画像生成部２６２から入力される画像信号に基づいてシステム管理のための各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図１のディスプレイモニタ１１０８がこれに該当する。
【０１０５】
通信制御部２７２は、データ通信に係るデータ処理を実行し、通信部３７２を介して外部装置とのデータのやりとりを実現する。
【０１０６】
通信部３７２は、通信回線１と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。
【０１０７】
サーバ記憶部５０２は、サーバ処理部２０２にサーバシステム１１００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームを管理するために必要なプログラム、各種データ等を記憶する。また、サーバ処理部２０２の作業領域として用いられ、サーバ処理部２０２が各種プログラムに従って実行した演算結果など一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図１ではブレードサーバ１１０２が搭載するＩＣメモリやハードディスクなどの情報記憶媒体がこれに該当する。
そして、本実施形態のサーバ記憶部５０２は、サーバシステムプログラム５１２と、ゲーム管理プログラム５１４と、ゲーム関連データ５１６とを記憶する。
【０１０８】
サーバシステムプログラム５１２は、サーバ処理部２０２が読み出して実行することでサーバシステム１１００に必要な基本的な入出力機能を実現する為のシステムプログラムである。ゲーム管理プログラム５１４は、サーバ処理部２０２が読み出して実行することで、ゲーム管理部２２０としての機能を実現させる為のプログラムである。
【０１０９】
図１０はゲーム関連データ５１６の一例を示す図である。ゲーム関連データ５１６は、カードの登録及びゲーム内に登場するキャラクタの初期設定に関する情報として、カード登録データ５１８と、複数の選手設定データ５２０と、複数のレンタル選手設定データ５３６と、複数の監督設定データ５４０と、を記憶する。
【０１１０】
また、リーグに関する情報として、リーグ設定データ５５０と、リーグ登録リスト５５１と、リーグ参加チームリスト５５２とを記憶する。
【０１１１】
また、試合のシミュレーションをする際に、各種攻撃戦術や守備戦術に対応した選手の具体的な行動を決定するための情報として、投球パターンデータ５５４と、打撃パターンデータ５５５と、守備シフトデータ５５６とを記憶する。
【０１１２】
また、試合のシミュレーションをする際に、攻撃チームの攻撃戦術を選択するための情報として、犠牲バント適当条件テーブル５６０と、犠牲バント選択確率テーブル５６１と、エンドラン適当条件テーブル５６２と、エンドラン選択確率テーブル５６３と、セーフティバント適当条件テーブル５６４と、セーフティバント選択確率テーブル５６５と、通常攻撃戦術選択確率テーブル５６６と、を記憶する。
【０１１３】
また、試合のシミュレーションをする際に、守備関連パラメータの守備戦術を選択するための情報として、敬遠選択条件テーブル５７０と、奇襲警戒適当条件テーブル５７２と、奇襲警戒選択確率テーブル５７４と、通常守備戦術選択確率テーブル５７６と、を記憶する。
【０１１４】
また、プレーヤが設定したチームに関する情報を格納する複数のチーム設定データ６００と、ゲームプレイに伴って随時生成・更新される情報を格納するプレイデータ６５０とを記憶する。その他、ゲームの管理制御に必要な、タイマ、カウンタ、フラグ、ログインしている携帯型ゲーム装置１４００のＩＰアドレスなどのデータ通信に必要な各種情報を適宜記憶するものとする。
【０１１５】
では、各データについて個別に詳細な説明をする。
カード登録データ５１８は、市販されているオブジェクト（トレーディングカード３）に割り当てられた各種情報を格納する。例えば、図１１に示すように、オブジェクト（トレーディングカード３）それぞれに固有に付与されているオブジェクト（カード）番号５１８ａと、当該番号に対応づけられる選手の識別情報である選手ＩＤ５１８ｂ（監督の場合には監督ＩＤに相当）と、販売シリーズの識別情報を格納するシリーズＩＤ５１８ｃと、使用済フラグ５１８ｄとを対応付けて記憶する。使用済フラグ５１８ｄは、「１」で当該オブジェクト（カード）が選手登録や監督登録に使用済で有ることを示し、「０」で未使用を示す。
【０１１６】
選手設定データ５２０は、野手，捕手，投手といった各種選手の種類を定義する情報であって、本実施形態の野球ゲームに登場する選手の種類だけ予め用意されている。
一つの選手設定データ５２０は、例えば、図１２に示すように、選手の名前などの識別情報を格納する選手ＩＤ５２０ａと、チーム編成画面Ｗ６（図５参照）などで表示される選手アイコン３０を表示させるための選手アイコンデータ５２０ｂと、試合画面表示部８２（図８参照）で野球をプレイする選手を表示させるための選手モデルデータ５２０ｃや選手テクスチャデータ５２０ｄ及び選手モーションデータ５２０ｅを記憶する。
【０１１７】
また、当該選手の特殊技能５２０ｆと、選手説明文５２０ｇと、実チームＩＤ５２０ｈとを記憶する。
【０１１８】
特殊技能５２０ｆは、特定の発動条件と、発動条件を満たした時に適用される当該選手固有の処理を定義した情報である。発動条件は、試合状況を示す各種パラメータ値（例えば、イニング数、アウトカウント、打順、ストライクやボールのカウント、進塁状況などを示す数値）で定義される。適用される処理は、例えば能力パラメータ値の増減値として定義される。
選手説明文５２０ｇは、選手登録画面Ｗ４や、チーム編成画面Ｗ６などの選手情報表示部１４，３４に表示されるテキスト情報を格納する）。
実チームＩＤ５２０ｈは、当該選手が現実の野球リーグにおいて所属するチームを識別する情報を格納する。
【０１１９】
また、選手設定データ５２０は、当該選手固有の能力や適性、行動傾向に関する情報として、攻撃関連パラメータ５２２と、守備関連パラメータ値５２４と、守備適性データ５２６と、個人戦術傾向パラメータ５３０とを記憶する。
【０１２０】
攻撃関連パラメータ５２２は、当該選手の打撃や走塁などの攻撃時の能力を定義する。例えば、安打率、長打力、ミート力、走力などのパラメータの値を適宜設定する。
守備関連パラメータ５２４は、当該選手の投球や守備などの守備時の能力を定義する。例えば、肩の強さ、制球力、最大球速、勝負球種（所謂決め球）などのパラメータの値を適宜設定する。
守備適性データ５２６は、当該選手がどこの守備ポジションに適性が有るかを示す情報であって、守備ポジション毎に守備適性値（０：適性無し〜１００：適性最大）を対応づけて格納する。
【０１２１】
個人戦術傾向パラメータ５３０は、プレイ中の打撃や走塁などの攻撃行動や守備行動にどういった行動を選択する傾向があるかの個人の好みを表す情報を格納する。例えば、図１３に示すように、攻撃戦術傾向パラメータ５３２と、守備戦術傾向パラメータ５３４とを格納する。
【０１２２】
攻撃戦術傾向パラメータ５３２は、例えば（１）数値が大きいほどカウントの早いうちから打ちに出る（打撃を試みる）傾向を示す「早打ち」、（２）数値が高いほど長打狙いを好むことを示す「長打」、（３）数値が大きいほどバント成功率が高いことを示す「バント」、（４）数値が大きいほど積極的に盗塁を狙う傾向を示す「走塁」、（５）数値が高いほど攻撃的なプレイを好む傾向、及び試合の序盤、中盤、終盤などの試合進行時期が後方になる程より積極的に攻撃に臨む傾向を示す「攻撃スタイル」、といったパラメータの項目とパラメータの値とを対応づけて格納する。パラメータの項目は、ゲーム内容などに応じて適宜設定できるのは言うまでも無い。
【０１２３】
守備戦術傾向パラメータ５３４は、例えば、（１）数値が大きいほどカウントの早い段階で勝負に出る傾向を示す「勝負カウント」、（２）数値が大きいほど打者の長打を警戒する傾向を示す「打撃警戒」、（３）数値が大きいほどセーフティバントやエンドラン、スクイズなどの奇襲を警戒する傾向を示す「奇襲警戒」、（４）数値が大きいほど敬遠策への許容が高いことを示す「敬遠」、（５）数値が高いほど手堅い守備を好む傾向、及び試合の序盤、中盤、終盤などの試合進行時期が後方になる程より厳重に守備に臨む傾向を示すことを示す「守備スタイル」、といったパラメータの項目とパラメータの値とを対応づけて格納する。パラメータの項目は、ゲーム内容などに応じて適宜設定できるのは言うまでも無い。
【０１２４】
尚、本実施形態では、攻撃戦術傾向パラメータ５３２及び守備戦術傾向パラメータ５３４は、基本的には中庸を示す「０」を格納するが、ゲームメーキングに影響を与える特定の選手（例えば、３冠王やゴールデングラブ賞を採るような高い能力を有する野手、投手、捕手）が−２〜＋２の間の数値を有し、スタメン全員のパラメータ値を合計しても−５〜＋５の間に収まるように、プラス値とマイナス値が適当に分散されて設定されている。勿論、これに限らず、全ての選手の全てのパラメータに適当な数値をばらけて設定する構成でも良い。
【０１２５】
レンタル選手設定データ５３６は、プレーヤが取得したオブジェクト（カード）が出場メンバー数に満たない場合に、自動的に貸し付けられる選手の設定データを格納する。データ構成は、基本的に選手設定データ５２０と同様に実現できる。但し、レンタル選手に付与される選手ＩＤは、レンタル選手固有とされる。つまり、オブジェクト（トレーディングカード３）に対応づけられている選手と、レンタル選手が仮に同一人物であったとしても、選手ＩＤは異なるので別キャラクタとして扱われることとなる。また、オブジェクト（トレーディングカード３）の購入意欲を減退させないために、レンタル選手は各種パラメータにおいて選手設定データ５２０で設定される正規の選手より劣るように設定されている。
【０１２６】
監督設定データ５４０は、選手についての選手設定データ５２０に相当するデータであって、監督についての各種設定情報を格納する。そして、ゲーム中に登場する監督の種類だけ予め用意される。
具体的には、例えば図１４に示すように、監督の名前などの識別情報を格納する監督ＩＤ５４０ａと、監督のオブジェクト（カード）登録のための画面などで表示される監督アイコンデータ５４０ｂと、特殊技能５４０ｆと、監督説明文５４０ｇと、実チームＩＤ５４０ｈと、個人戦術傾向パラメータ５４２とを含む。個人戦術傾向パラメータ５４２は、選手設定データ５２０のそれと同様に、攻撃戦術傾向パラメータ５４４と守備戦術傾向パラメータ５４６とを含む。
【０１２７】
リーグ設定データ５５０は、プレーヤが作成したリーグの設定情報を格納するデータであり、作成されたリーグ毎に用意される。本実施形態では、例えば図１５に示すように、リーグの名称などの識別情報を格納するリーグＩＤ５５０ａと、参加パスワード５５０ｂと、レギュレーション設定データ５５０ｃとを含む。レギュレーション設定データ５５０ｃは、レギュレーションの項目毎に設定内容を対応付けて格納する。
【０１２８】
リーグ登録リスト５５１は、プレーヤにより作成された全てのリーグのリストであって、リーグＩＤと参加パスワードとを対応づけて格納する。
【０１２９】
リーグ参加チームリスト５５２は、各リーグに現在参加しているチームの情報を格納するデータセットであって、対応するリーグ毎に用意される。一つのリーグ参加チームリスト５５２には、例えば図１６に示すように、対応するリーグＩＤを格納する対応リーグＩＤ５５２ａと、参加チームＩＤ５５２ｂに対応付けられたチーム成績５５２ｃとが格納される。
【０１３０】
投球パターンデータ５５４は、１打席における配球内容を決定するための基礎情報であって、守備戦術の種類に応じた数だけ予め用意される。
例えば、図１７に示すように、バント対応パターン、エンドラン対応パターン、「早め勝負・長打警戒」対応パターン・・・と言った具合に各種投球パターンが用意されている。一つの投球パターン５５４ａは、投球順５５４ｂ毎に、勝負球（決め球）選択確率５５４ｃと、投球ゾーン別選択確率５５４ｄと、球速選択確率５５４ｅと、球威選択確率５５４ｆとが対応付けて格納されている。投球内容は、これらの確率に基づく抽選で決定される。
【０１３１】
打撃パターンデータ５５５は、１打席においてどのように打撃をするかを決定するための基礎情報であって、攻撃戦術の種類に応じた数だけ予め用意される。
本実施形態では、例えば図１８に示すように、犠牲バント対応パターン、ヒットエンドラン対応パターン、「早打ち・長打狙い」対応パターン、・・・と言った具合に用意される。そして、一つの対応パターンは、投球順５５５ａと対応づけて、ジャストミート確率５５５ｂと、標準ミート確率５５５ｃと、打ち損ね確率５５５ｄと、見送り確率５５５ｅとが格納されている。打撃内容は、これらの確率に基づく抽選で決定される。
勿論、打撃パターンの設定の仕方はこれに限らず、スイングの是非、スイングの位置（内角高め、内角中央、内角低め、外角高め、外角中央、外角低め、中央）、スイングタイミングのジャストミート／遅い／早い、と言った項目の各確率を格納するとしても良い。
【０１３２】
守備シフトデータ５５６は、守備戦術の種類に応じて各守備ポジションの守備位置を決定する為のデータであって、守備戦術毎に標準の守備位置に対する相対位置を格納する。
【０１３３】
犠牲バント適当条件テーブル５６０は、攻撃戦術「犠牲バント」を選択するのが適当とする条件を定義する。例えば、図１９に示すように、出塁状況５６０ａと対応づけて、打者の「ミート力」や「走力」などの攻撃関連パラメータ値５２２をファクタとする適当条件５６０ｂを格納する。
【０１３４】
犠牲バント選択確率テーブル５６１は、攻撃戦術「犠牲バント」が適当と判断される場合に、実際に犠牲バントが選択される確率を定義する。例えば、図２０に示すように、最終攻撃戦術傾向パラメータの「バント」の値５６１ａと、攻撃チーム側から見た得点差５６１ｂとの相関関係で選択確率を格納する。
【０１３５】
エンドラン適当条件テーブル５６２は、攻撃戦術「エンドラン（ヒットエンドランの略）」を選択するのが適当とする条件を定義する。データ構成は、犠牲バント適当条件テーブル５６０と同様に実現できる。すなわち、適当条件５６０ｂのファクタとする攻撃側のパラメータを、例えば打者の「ミート力」と走者の「走力」に置き換えれば良い。
【０１３６】
エンドラン選択確率テーブル５６３は、攻撃戦術「エンドラン」が適当と判断される場合に、実際にエンドランが選択される確率を定義する。データ構成は、犠牲バント選択確率テーブル５６１における「バント」の値を、最終攻撃戦術傾向パラメータの「走塁」の値に置き換えることで同様に実現できる。
【０１３７】
セーフティバント適当条件テーブル５６４は、攻撃戦術「セーフティバント」を選択するのが適当とされる条件を定義する。本実施形態では、打者の「ミート力」と「走力」がともに所定の基準値を超えていることを適合条件とする。勿論、打者の「ミート力」と「走力」との相関関係に基づいて適当条件を満たす確率を定義しても良い。
【０１３８】
セーフティバント選択条件テーブル５６５は、セーフティバントが適当と判断される場合に、実際にセーフティバントが選択される確率を定義する。犠牲バント選択確率テーブル５６１と同様に、最終攻撃戦術傾向パラメータの「バント」の値と、攻撃チーム側から見た得点差とのマトリクスで選択確率を格納する。
【０１３９】
攻撃戦術選択確率テーブル５６６は、ヒッティングの戦術を選択する確率を定義する。本実施形態では、「早打ち・長打狙い」「遅打ち・長打狙い」「早打ち・短打狙い」「遅打ち・短打狙い」の４種の戦術が選択可能である。当該テーブルでは、図２１に示すように、最終攻撃戦術傾向パラメータの「長打」の値５６６ａと、「早打ち」の値５６６ｂとの相関関係に基づいて、４種の戦術それぞれの選択確率を格納する。
【０１４０】
敬遠選択条件テーブル５７０は、守備戦術「敬遠」が選択される条件を定義する。本実施形態では、図２２に示すように、最終守備戦術傾向パラメータの「敬遠」の値５７０ａと、打者の「ミート力」及び「長打力」の合計５７０ｂとの相関関係に基づいて、選択される確率を格納する。
【０１４１】
奇襲警戒適当条件テーブル５７２は、守備戦術「奇襲警戒」、つまりセーフティバントやエンドランを警戒した戦術を選択するのが適当とする条件を定義する。例えば、図２３に示すように、出塁状況５７２ａの条件別に、打者の「ミート力」と「走力」をファクタとする適当条件５７２ｂを格納する。
【０１４２】
奇襲警戒選択確率テーブル５７４は、奇襲警戒が適当と判断される場合に、実際に奇襲警戒が選択される確率を定義する。例えば、図２４に示すように、最終守備戦術傾向パラメータの「奇襲警戒」の値５７４ａと、守備チーム側を主観とした得点差５７４ｂとの相関関係に基づいて選択される確率を格納する。
【０１４３】
通常守備戦術選択確率テーブル５７６は、ピッチングの戦術を選択する確率を定義する。本実施形態では、「早め勝負・長打警戒」「遅め勝負・長打警戒」「早め勝負・短打警戒」「遅め勝負・短打警戒」の４種から選択可能である。そして、例えば図２５に示すように、最終守備戦術傾向パラメータの「打撃警戒」の値５７６ａと、最終守備戦術傾向パラメータの「勝負カウント」の値５７６ｂとの相関関係に基づいて、上記４種の守備戦術別の選択確率を格納する。
【０１４４】
チーム設定データ６００は、プレーヤ毎に用意され、プレーヤが作成したチームの情報を格納する。例えば、図２６に示すように、プレーヤＩＤ６０２と、パスワード６０４と、チームＩＤ６０６と、監督登録リスト６０８と、選手登録リスト６１０と、スタメンリスト６１２と、交代要員リスト６１４と、控え投手リスト６１６と、参加リーグＩＤ６１８と、を含む。
【０１４５】
監督登録リスト６０８は、当該プレーヤが既に登録した監督の情報が格納される。例えば、どのオブジェクト（トレーディングカード３）の監督オブジェクト（カード３ａ）が登録されたかを示す情報として、そのオブジェクト（カード）に対応する監督ＩＤ６０８ａと、シリーズＩＤ６０８ｂとを格納する。また、同種オブジェクト（カード）が重複して登録された回数を示す同一監督重複登録数６０８ｃと、適用個人戦術傾向パラメータ６０８ｄとを格納する。
新規に登録される場合には、適用個人戦術傾向パラメータ６０８ｄには監督設定データ５４０の個人戦術傾向パラメータ５４２がコピーされ、同種カードの重複登録に伴う特典の付与として、パラメータ値が「０」以外のパラメータ値が所定値加算されて更新される。つまり、その監督の戦術傾向がより際だつようになる。
【０１４６】
選手登録リスト６１０は、当該プレーヤが既に登録しているオブジェクト（カード）に対応する選手の情報が格納されているデータセットが複数格納されている。一つのデータセットには、どのオブジェクト（トレーディングカード３）の選手オブジェクト（カード３ｂ）が登録されたかを示す情報として選手ＩＤ６１０ａとシリーズＩＤ６１０ｂとが含まれる。また、同一選手重複登録数６１０ｃと、適用攻撃関連パラメータ６１０ｄと、適用守備関連パラメータ６１０ｅと、適用個人戦術傾向パラメータ６１０ｆとが含まれる。
【０１４７】
シリーズＩＤ６１０ｂは、登録選手に対応づけられたオブジェクト（トレーディングカード３）の販売シリーズの識別情報である。新規登録される場合には、オブジェクト（カード）登録データ５１８（図１１参照）のシリーズＩＤ５１８ｃがコピーされる。
同一選手重複登録数６１０ｃは、同種のオブジェクト（カード）が何回登録されたかを示す。当然、新規に登録される場合には「１」に設定され、同種のカードが登録操作される都度「１」加算される。
【０１４８】
適用攻撃関連パラメータ６１０ｄと適用守備関連パラメータ６１０ｅは、それぞれ当該選手に試合のシミュレーション処理において適用される攻撃力及び守備力に関する各種パラメータ値を格納する。新規に登録される場合には、当該選手に対応する選手設定データ５２０（図１２参照）の攻撃関連パラメータ５２２及び守備関連パラメータ５２４がそのまま格納される。そして、同じオブジェクト（カード）が複数回登録されると、その回数に応じて特典として加算補正される。
【０１４９】
適用個人戦術傾向パラメータ値６１０ｆは、どういった攻撃や守備をするかその傾向に関する各種パラメータ値を格納する。新規に登録される場合には、当該選手に対応する選手設定データ５２０の個人戦術傾向パラメータ値５３０がコピーされる。そして、チーム能力に関する特典付与の一つとして変更され、試合のシミュレーション処理において適用される。本実施形態では、チーム編成されている選手の適用個人戦術傾向パラメータ６１０ｆに基づいてチームの戦術傾向パラメータを決定するので、適用個人戦術傾向パラメータ６１０ｆの変更はチームのパラメータの一部を変更することにほかならない。
【０１５０】
スタメンリスト６１２は、スターティングメンバーとした登録した選手の守備ポジションと、打順などの情報を格納する。例えば、図２７に示すように、スタメンリスト６１２は、守備のポジション６１２ａ毎に、当該ポジションに割り当てられた選手の選手ＩＤ６１２ｂと、打順６１２ｃとを対応付けて格納する。
【０１５１】
交代要員リスト６１４は、交代要員として登録した選手と、交代目的の設定情報を格納する。
控え投手リスト６１６は、控え投手として登録された選手の選手ＩＤと対応づけて、「中継ぎ」や「抑え」といった交代目的を示す情報が格納されている。
参加リーグＩＤ６１８は、当該チームが現在参加しているリーグＩＤを格納する。
【０１５２】
プレイデータ６５０は、試合毎に生成され、試合状況を示す情報や、試合を制御する為の各種情報を格納する。例えば、図２８に示すように、試合する２チームのチームＩＤ等を格納する対戦チーム情報６５２と、現在のイニング数とその表裏の識別情報を格納するイニング情報６５４と、試合に参加している全選手の各種パラメータを選手ＩＤと対応づけて格納する選手パラメータデータ６５６と、交代要員や控え投手の内すでに交代が行われた選手の選手ＩＤを格納する交代済選手リスト６５８と、基礎攻撃傾向パラメータ６６０と、基礎守備傾向パラメータ６６２と、中間攻撃傾向パラメータ６６４と、中間守備傾向パラメータ６６６と、最終攻撃傾向パラメータ６６８と、最終守備傾向パラメータ６７０とを格納する。
【０１５３】
［動作の説明］
次に、本実施形態におけるサーバシステム１１００の動作について説明する。尚、既にユーザ登録を済ませたプレーヤが、適宜携帯型ゲーム装置１４００を使ってログインした状態にあるものとする。
【０１５４】
図２９は、サーバシステム１１００の本実施形態における主たる処理の流れを説明するためのフローチャートである。
サーバシステム１１００のサーバ処理部２０２は、先ず携帯型ゲーム装置１４００へメニュー画面Ｗ２を表示させるための表示情報を送信する（ステップＳ２）。
表示情報は、例えば携帯型ゲーム装置１４００の画像表示に用いるプログラムがウェブブラウザであれば、ＨＴＭＬ情報などである。携帯型ゲーム装置１４００にて何らかの操作入力が行われると、サーバシステム１１００へ操作入力に応じたリクエスト情報が送信される。
【０１５５】
受信したリクエスト情報から、携帯型ゲーム装置１４００にて野手及び投手を登録するための「選手登録」が選択されたと判定される場合（ステップＳ４のＹＥＳ）、サーバ処理部２０２は選手登録処理を実行する（ステップＳ６）。
【０１５６】
図３０は、本実施形態における選手登録処理の流れを説明するためのフローチャートである。同処理において、サーバ処理部２０２は先ず、携帯型ゲーム装置１４００へ選手登録画面Ｗ４（図４参照）を表示させるための情報、より具体的にはカード番号入力欄１０と、番号入力用のソフトウェアキーボード１２とを表示させるための表示情報やＪａｖａ（登録商標）プログラム、及び当該プレーヤが登録している登録選手一覧１６を表示させる為のＣＧＩソースなどを携帯型ゲーム装置１４００へ送信する（ステップＳ１０）。
携帯型ゲーム装置１４００で、オブジェクト（カード）番号入力欄１０に番号が入力され登録操作すると、ソフトウェアキーボード１２への操作入力情報に基づいたオブジェクト（カード）番号とともに、そのオブジェクト（カード）の使用登録要求となるリクエスト情報がサーバシステム１１００へ送信される。
【０１５７】
サーバ処理部２０２は、携帯型ゲーム装置１４００から受信したリクエスト情報が新規のオブジェクト（カード）の使用登録操作に該当する場合には（ステップＳ１２のＹＥＳ）、リクエスト情報とともに受信した番号をオブジェクト（カード）登録データ５１８（図１１参照）と照合する（ステップＳ１４）。
【０１５８】
正規のオブジェクト（カード）として登録されているオブジェクト（カード）番号の何れかと受信したオブジェクト（カード）番号とが合致しなければ（ステップＳ１４の不一致）、サーバ処理部２０２は、携帯型ゲーム装置１４００の選手登録画面Ｗ４で入力したオブジェクト（カード）番号が登録できない旨通知表示させるための情報を送信する（ステップＳ１８）。
【０１５９】
正規のオブジェクト（カード）として登録されているオブジェクト（カード）番号の何れかと受信したオブジェクト（カード）番号とが合致すれば（ステップＳ１４の合致）、サーバ処理部２０２は、さらに受信したオブジェクト（カード）番号に対応するオブジェクト（トレーディングカード３）が未使用であるか、すなわち選手登録に使用されていないかを判定する（ステップＳ１６）。
【０１６０】
そして、もし未使用であれば（ステップＳ１６のＴＲＵＥ）、サーバ処理部２０２は当該プレーヤのチーム設定データ６００の選手登録リスト６１０を参照して、同種のオブジェクト（カード）が既に登録されているかを判定する（ステップＳ２０；図２１参照）。
具体的には、オブジェクト（カード）登録データ５１８を参照して、受信したオブジェクト（カード）番号５１８ａに対応づけられている選手ＩＤ５１８ｂ及びシリーズＩＤ５１８ｃの組み合わせと、選手登録リスト６１０（図２６参照）の登録済の選手ＩＤ６１０ａ及びシリーズＩＤ６１０ｂの組み合わせとが合致するものがあれば同種オブジェクト（カード）が登録済と判定し、合致するものが無ければ未登録と判定する。尚、レンタル選手が選手登録リスト６１０に登録されていても、今回新たに登録されるオブジェクト（トレーディングカード３）に対応する選手とレンタル選手とが同一人物であったとしても、そもそもレンタル選手にはレンタル選手固有の選手ＩＤが付与されるので、当該ステップでは同種カードとは認識されないことになる。
【０１６１】
そして、未登録であれば（ステップＳ２０のＮＯ）、サーバ処理部２０２は、当該受信したオブジェクト（カード）番号に対応する選手を新規登録する（ステップＳ２２）。
すなわち、選手登録リスト６１０に、受信したオブジェクト（カード）番号の選手ＩＤ５１８ｂを新たな選手ＩＤ６１０ａとして登録する。そして、これに対応付けて、シリーズＩＤ５１８ｃをコピーしたシリーズＩＤ６１０ｂを格納し、同一選手重複登録数６１０ｃとして初期値「１」を格納する。また、適用攻撃関連パラメータ６１０ｄ及び適用守備関連パラメータ６１０ｅは、それぞれ選手設定データ値５２０（図１２参照）の攻撃関連パラメータ５２２及び守備関連パラメータ５２４の初期設定値そのままをコピーして格納する。また、適用個人戦術傾向パラメータ６１０ｆは、個人戦術傾向パラメータ５３０の初期設定値そのままをコピーして格納する。
【０１６２】
もし、受信したオブジェクト（カード）番号に対応する選手が既に登録されている場合には（ステップＳ２０のＹＥＳ）、サーバ処理部２０２は、選手登録リスト６１０に登録されている選手のうち、同種オブジェクト（カード）と見なされる選手の同一選手重複登録数６１０ｃに今回登録のオブジェクト（カード）の分「１」を加算して更新する（ステップＳ２４）。
【０１６３】
次いで、携帯型ゲーム装置１４００の選手登録画面Ｗ４にて受信したオブジェクト（カード）番号に対応するキャラクタの選手情報表示欄１４に表示させるための表示情報を送信する（ステップＳ２６）。尚、ここでの表示情報には、同一選手重複登録数１４ｄ（図４参照）を表示させるための情報と、同一選手重複登録数が複数の場合には、特典付与状態マーク１４ｅを表示させるための情報を含めるものとする。
【０１６４】
次いで、サーバ処理部２０２は、受信したオブジェクト（カード）番号に対応するキャラクタの更新後の同一選手重複登録数６１０ｃが、特典付与最低基準値（重複登録数条件に相当。例えば、２〜４程度の値。）以上であって（ステップＳ２８のＹＥＳ）、且つ特典付与上限値（例えば、５〜１０程度の値）未満であれば（ステップＳ３０のＹＥＳ）、サーバ処理部２０２は、チーム設定データ６００の選手登録リスト６１０の適用攻撃関連パラメータ６１０ｄ及び適用守備関連パラメータ６１０ｅの中から、先に算出した同一選手重複登録数６１０ｃと同数だけ特典付与対象とするパラメータをランダムに選択する（ステップＳ３２）。
尚、特典付与対象とするパラメータは、ランダム選択に限らず、相対的に他より値が高いパラメータを選択して当該選手の特徴をより増長させるようにしても良い。
【０１６５】
そして、選択した特典付与対象のパラメータの値を加算して更新する（ステップＳ３４）。具体的には、例えば（初期設定値×（同一選手重複登録数×０．０１＋１．０））で加算補正された値を算出するとしても良い。加算量は、パラメータ値の設定範囲に応じて、特典付与によって過剰に特異な能力を有しないように適当に設定すると良い。
【０１６６】
一方、同一選手重複登録数が複数であるが、特典付与上限値に達している場合には（ステップＳ３０のＮＯ）、選手能力のバランスを考慮して特典は付与しない。
【０１６７】
そして、携帯型ゲーム装置１４００からメニュー画面への復帰操作に該当するリクエスト情報を受信した場合には（ステップＳ３６のＹＥＳ）、サーバ処理部２０２は選手登録処理を終了する。
【０１６８】
選手登録処理を終了したならば、図２９のフローチャートに戻って、リクエスト情報から「監督登録」が選択されたと判定される場合（ステップＳ５０のＹＥＳ）、サーバ処理部２０２は監督登録処理を実行する（ステップＳ５２）。
【０１６９】
監督登録処理は、オブジェクト（カード）に対応するキャラクタが監督であるだけで、基本的には選手登録処理と同じである。但し、監督には、選手のように攻撃関連パラメータ及び守備関連パラメータが設定されていないので、選手登録処理のステップＳ３２〜Ｓ３４に相当するステップでは、適用個人戦術パラメータ６０８ｄのうち、設定値が「０」以外の項目のパラメータ値に所定値を加算する処理をする。
【０１７０】
受信したリクエスト情報が「チーム編成」の選択操作に該当する場合には（ステップＳ１００のＹＥＳ）、サーバ処理部２０２はチーム編成処理を実行する（ステップＳ１０２）。
【０１７１】
図３１〜図３２は、チーム編成処理の流れを説明するためのフローチャートである。
サーバ処理部２０２は、先ずスタメン編成タグが選択された状態のチーム編成画面Ｗ６（図５参照）の表示処理を行う（ステップＳ１２２）。即ち、携帯型ゲーム装置１４００でスタメン設定状態表示部２６を表示させる表示情報と、登録選手一覧３６を表示させるための表示情報とを送信する。
【０１７２】
携帯型ゲーム装置１４００では、スタメン設定状態表示部２６の各守備ポジションのうち、当該プレーヤのチーム設定データ６００のスタメンリスト６１２（図２７参照）の選手ＩＤ６１２ｂが登録されているポジションについては、当該選手ＩＤ６１２ｂの示す選手設定データ５２０の選手アイコンデータ５２０ｂ（図１２参照）又はレンタル選手設定データ５３６の選手アイコンデータが表示され、未登録の守備ポジションにはブランクのアイコン３２が表示される。また、登録選手一覧３６には、同一覧の所定表示位置に当該プレーヤのチーム設定データ６００の選手登録リスト６１０に登録されている選手の選手アイコンが表示される。
【０１７３】
携帯型ゲーム装置１４００にて、スタメン設定状態表示部２６の内、プレーヤが選手の設定をしたいと思う守備ポジションの選択操作や、登録選手一覧３６に表示されているアイコンから選択したポジションへ登録したい選手の選択操作、ポジションの設定を解除する「はずす」操作などを入力すると、それらの操作入力に応じたリクエスト情報がサーバシステム１１００へ送信される。
【０１７４】
サーバシステム１１００で受信したリクエスト情報が守備ポジションの選択操作に該当する場合（ステップＳ１２４のＹＥＳ）、サーバ処理部２０２は選択された守備ポジションの識別情報を一時的にサーバ記憶部５０２に格納して、当該守備ポジションを設定対象ポジションとする（ステップＳ１２６）。そして、選手情報表示部３４の表示処理を実行して（ステップＳ１２８）、携帯型ゲーム装置１４００にて、現在設定対象とされている守備ポジションに登録されている選手に係る情報を選手情報表示部３４に表示させるための情報を携帯型ゲーム装置１４００へ送信する。
【０１７５】
そして、受信したリクエスト情報が「はずす」操作に該当する場合（ステップＳ１４０のＹＥＳ）、サーバ処理部２０２はスタメンリスト６１２（図２７参照）において現在設定対象とされている守備ポジションに対応づけて格納されている選手ＩＤ６１２ｂなどのデータをクリアして登録を解除する（ステップＳ１４２）。そして、選手詳細表示部３４の表示を削除してクリアするための処理を実行する（ステップＳ１４４）。
【０１７６】
もし、受信したリクエスト情報が選手の守備ポジションに該当する場合、すなわち設定対象ポジションが選択された状態で登録選手一覧３６の何れかの選手のアイコンを選択する操作が為された場合、又は登録選手一覧３６の何れかの選手のアイコンの設定対象ポジションへのドラック・アンド・ドロップ操作が為された場合（ステップＳ１４６のＹＥＳ）、サーバ処理部２０２は、登録先となる現在の設定対象とされる守備ポジション、又はドロップ先の守備ポジションに既に登録されている選手が有るかを判定する（ステップＳ１５０）。
【０１７７】
もし、既に登録されている選手が無ければ（ステップＳ１５０のＮＯ）、サーバ処理部２０２は、登録選手一覧３６で選択されたアイコン又はドラッグされたアイコンに対応する選手を登録先の守備ポジションに登録し（ステップＳ１５２）、次いで選手情報表示部３４の表示を、選択されたアイコンに対応する選手の表示に変更させる為の情報を送信する（ステップＳ１５４）。反対に登録先の守備ポジションに既に登録されている選手が有る場合（ステップＳ１５０のＹＥＳ）、サーバ処理部２０２は指定重複登録処理を実行する（ステップＳ１６０）。
【０１７８】
図３３は、本実施形態における指定重複処理の流れを説明するためのフローチャートである。同処理では先ず、サーバ処理部２０２は、登録先とされる守備ポジションに登録されている選手が、登録選手一覧３６から選択されたアイコン又はドラック・アンド・ドロップ操作されたアイコンの選手と同じであるかを判定する（ステップＳ１６２）。この場合、当該選手に対応するオブジェクト（トレーディングカード３）のシーズンの違いは問わない。
【０１７９】
もし、否定判定された場合、即ち既に選手が登録されている守備ポジションに違う種類の選手（異なる人物の意）を登録しようとした場合には（ステップＳ１６２のＮＯ）、サーバ処理部２０２は携帯型ゲーム装置１４００にて設定対象の守備ポジションの選手登録を「はずす」ように促す表示をさせるための処理を実行する（ステップＳ１６４）。
もし、肯定判定された場合、即ち既に登録されている選手と同じ選手を重複して登録しようとした場合には（ステップＳ１６２のＹＥＳ）、サーバ処理部２０２は設定対象ポジションに登録されている選手、又はドロップ先の守備ポジションに登録されている選手の同一選手重複登録数６１０ｃを「１」加算して更新する（ステップＳ１６６）。
【０１８０】
次いで、サーバ処理部２０２は、その更新した後の同一選手重複登録数６１０ｃが所定の特典付与上限に達していなければ（ステップＳ１６８のＹＥＳ）、当該選手の適用攻撃関連パラメータ６１０ｄ及び適用守備関連パラメータ６１０ｅの中から補正後の同一選手重複登録数６１０ｃの数だけパラメータを特典付与対象としてランダムに選択する（ステップＳ１７０）。そして、特典付与対象のパラメータの値に所定値を加算して更新し（ステップＳ１７２）、重複して登録しようとした選手の情報を選手登録リスト６１０から抹消する（ステップＳ１７４）。次いで、サーバ処理部２０２は、選手情報表示部３４の表示を更新させるための情報を送信し（ステップＳ１７６）、指定重複登録処理を終了する。
【０１８１】
尚、この場合の重複登録は、同じ選手を想起させるが意匠違いのオブジェクト（カード）の登録を纏めることになるので、ステップＳ１７２で特典として加算される値は、選手登録処理における重複登録の特典付与（図３０のステップＳ３２）の時より高くするとゲームの興趣を高める上で好適である。更には、選手登録リスト６１０にて、指定重複登録処理で重複登録されたオブジェクト（カード）のシリーズＩＤの履歴を格納する構成として、重複使用登録されたオブジェクト（カード）のシリーズが所定数連続する（例えば、第１弾から第３弾までのような３つ連続するなど）など特定の条件を満たす場合に、更に異なる加算値を設定する構成とするならば、より一層ゲームの興趣を高める上で好適である。
【０１８２】
もし、更新した後の同一選手重複登録数６１０ｃが所定の特典付与上限に達しているならば（ステップＳ１６８のＮＯ）、ステップＳ１７０〜Ｓ１７６はスキップして、指定重複登録処理を終了する。
【０１８３】
図３２のフローチャートに戻って、サーバシステム１１００で受信したリクエスト情報が交代要員編成タグ２２の選択操作に該当する場合には（ステップＳ１９０のＹＥＳ）、サーバ処理部２０２は、交代要員の編成処理を実行する（ステップＳ１９２）。同処理では、例えば交代要員の登録枠と、登録選手一覧３６とを表示させ、登録選手一覧３６に表示される選手アイコンを登録枠へドラック・アンド・ドロップ操作することで交代要員を設定する。
【０１８４】
また、サーバシステム１１００で受信したリクエスト情報が控え投手編成タグ２４の選択操作に該当する場合には（ステップＳ１９４のＹＥＳ）、サーバ処理部２０２は控え投手の編成処理を実行する（ステップＳ１９６）。同処理では、例えば控え投手の登録枠と、登録選手一覧３６とを表示させ、登録選手一覧３６に表示される選手アイコンを登録枠へドラック・アンド・ドロップ操作することで控え投手を登録する。
【０１８５】
次に、サーバ処理部２０２は、選手登録リスト６１０に登録されている全選手が、スタメン、控え投手、交代要員の何れかに設定されていて（ステップＳ２００のＹＥＳ）、且つ、それでいて選手が登録されていない守備ポジションが有るかを判定する（ステップＳ２０２）。すなわち、選手登録された分ではゲームプレイに不足するかを判定する。
【０１８６】
該当する守備ポジションがあるならば（ステップＳ２０２のＹＥＳ）、サーバ処理部２０２はレンタル選手設定データ５３６から何れかの選手をランダムに選択して、該当する守備ポジションへ自動登録処理するとともに、選手登録リスト６１０にも選択されたレンタル選手を自動登録する（ステップＳ２０４）。そして、携帯型ゲーム装置１４００でその旨通知する為の処理を実行する（ステップＳ２０６）。
該当する守備ポジションがなければ（ステップＳ２０２のＮＯ）、ステップＳ２０４とＳ２０６はスキップされる。
【０１８７】
これまでの処理で、チーム編成ができたことになる。プレーヤはチーム編成を終了するためにメニュー画面Ｗ２への復帰操作をすることとなる。そして、サーバシステム１１００で受信したリクエスト情報がメニュー画面Ｗ２への復帰操作に該当する場合には（ステップＳ２０８のＹＥＳ）、サーバ処理部２０２はチームパラメータ変更処理を実行する（ステップＳ２１０）。
【０１８８】
図３４は、本実施形態におけるチームパラメータ変更処理の流れを説明するためのフローチャートである。同処理は、重複登録された選手の組み合わせに応じてチームパラメータを自動的に変更して特典を付与するための処理である。
【０１８９】
同処理では先ず、サーバ処理部２０２は、選手登録リスト６１０から同一選手重複登録数６１０ｃが複数である選手を抽出する（ステップＳ２５０）。
そして、抽出された選手が所定のポジション条件を満たすか否かを判定する（ステップＳ２５２）。ここで言う「ポジション条件」とは、重複登録された選手の守備ポジションの組み合わせである。本実施形態では、「投手and捕手（バッテリー）」とするが、それ
以外にも「ライトandセンターandレフト」など適宜設定できる。
【０１９０】
そして、抽出された選手がポジション条件を満たす場合（ステップＳ２５２のＹＥＳ）、サーバ処理部２０２は、ポジション条件を満たす選手の適用攻撃関連パラメータ６１０ｄ及び適用守備関連パラメータ６１０ｅのうち所定の項目のパラメータ値を、パラメータが向上するように所定量変更する（ステップＳ２５４）。
【０１９１】
更に、サーバ処理部２０２は、適用個人戦術傾向パラメータ６１０ｆのうち所定の項目のパラメータ値を所定量変更する（ステップＳ２５６）。
適用個人戦術傾向パラメータ６１０ｆは、チームの戦術決定に影響を与えるファクタであるから、適用個人戦術傾向パラメータ６１０ｆの変更はとりもなおさずチームパラメータの変更となる。尚、ゲーム内容によっては、例えばチーム編成するＲＰＧ（role-playing game）におけるチーム移動速度などのようにチーム全体に適用されるパラメータ値が存在する場合には、ステップＳ２５６では、そうしたパラメータ値を変更すれば良い。
【０１９２】
抽出された選手がポジション条件を満たさなければ（ステップＳ２５２のＮＯ）、ステップＳ２５４からＳ２５６はスキップされる。
【０１９３】
次に、サーバ処理部２０２は、抽出された選手が所定の実チーム条件を満たすかを判定する（ステップＳ２５８）。ここで言う「実チーム条件」とは、抽出された選手が実際の野球リーグにおいて所属するチームの組み合わせを示す条件である。本実施形態では「同一チーム」とするが、サッカーやＲＰＧなどその他のゲーム内容では「敵対する国のチーム」「同じ国のリーグに属するチーム」などゲーム世界の背景設定に応じて適宜設定することができる。
【０１９４】
そして、もし所定の実チーム条件を満たした場合には（ステップＳ２５８のＹＥＳ）、サーバ処理部２０２は抽出された選手の適用個人戦術傾向パラメータ６１０ｆのうち所定の項目のパラメータ値を所定量変更する（ステップＳ２６０）。
【０１９５】
次いでサーバ処理部２０２は、当該チームの監督の同一監督重複登録数６０８ｃが複数である場合（ステップＳ２６２のＹＥＳ）、当該監督の適用個人戦術傾向パラメータ６０８ｄのうち所定の項目のパラメータ値を所定量変更して（ステップＳ２６４）、チームパラメータ変更処理を終了する。もし、同一監督重複登録数６０８ｃが単数であれば（ステップＳ２６２のＮＯ）、ステップ２６２をスキップしてチームパラメータ変更処理を終了する。
【０１９６】
チームパラメータ変更処理を終了したならば、サーバ処理部２０２はチーム編成処理を終了し、図２９のフローチャートに戻る。
【０１９７】
メニュー画面Ｗ２において、受信したリクエスト情報が「リーグ作成」に該当する場合（ステップＳ３００のＹＥＳ）、サーバ処理部２０２はリーグ作成処理を実行する（ステップＳ３０２）。
【０１９８】
図３５は、リーグ作成処理の流れを説明するためのフローチャートである。サーバ処理部２０２は、先ずリーグ設定画面表示処理を実行し、リーグ設定画面Ｗ１０（図６参照）を表示させるための表示情報を携帯型ゲーム装置１４００へ送信する（ステップＳ３０４）。そして、新たなリーグ設定データ５５０を準備する（ステップＳ３０６；図１５参照））。この時、レギュレーション設定データ５５０ｃの各項目の設定内容は所定のデフォルトとされる。
【０１９９】
携帯型ゲーム装置１４００でリーグ設定画面Ｗ１０における操作入力がなされると、リーグＩＤ設定欄６０、参加パスワード設定欄６２、レギュレーション設定部６６への各種操作入力に応じたリクエスト情報がサーバシステム１１００へ送信される。
【０２００】
サーバ処理部２０２は、リーグＩＤ設定欄６０、参加パスワード設定欄６２への操作入力に基づくリクエスト情報を受信して、先に生成したリーグ設定データ５５０のリーグＩＤ５５０ａ、参加パスワード５５０ｂを設定する（ステップＳ３０８）。
また、レギュレーション設定部６６への操作入力に基づくリクエスト情報を受信して、先に生成したリーグ設定データ５５０のレギュレーション設定データ５５０ｃの各項目の設定内容を変更する（ステップＳ３１０）。
【０２０１】
次に、サーバ処理部２０２は、受信したリクエスト情報が設定終了操作に該当する場合（ステップＳ３１２のＹＥＳ）、今回新たに生成したリーグのリーグＩＤと参加パスワードとを対応づけてリーグ登録リスト５５１に追加登録する（ステップＳ３１４）。そして、当該リーグに対応する新たなリーグ参加チームリスト５５２を生成する（ステップＳ３１６；図１６参照）。
【０２０２】
もし、受信したリクエスト情報が現在の設定内容を全て破棄する「全クリア」に該当する場合には（ステップＳ３１８のＹＥＳ）、サーバ処理部２０２は今回新たに作成したリーグ設定データ５５０を削除する（ステップＳ３２０）。
【０２０３】
そして、受信したリクエスト情報がメニュー画面への復帰操作に該当する場合（ステップＳ３２２のＹＥＳ）、サーバ処理部２０２はリーグ作成処理を終了する。
【０２０４】
図２９のフローチャートに戻って、リクエスト情報から「リーグ参加」が選択されと判定される場合（ステップＳ３５０のＹＥＳ）、サーバ処理部２０２はリーグ参加処理を実行する（ステップＳ３５２）。
【０２０５】
リーグ参加処理は、プレーヤの操作入力に応じて、既に作成されているリーグへの参加登録のための処理である。
具体的には、サーバ処理部２０２は、携帯型ゲーム装置１４００へ参加リーグ設定画面Ｗ１２表示させるための表示情報を送信する（図７参照）。携帯型ゲーム装置１４００では、ソフトウェアキーボード７４によりリーグＩＤ入力欄７０と参加パスワード入力欄７２への入力が可能になり、入力に応じたリクエスト情報がサーバシステム１１００へ送信される。そして、受信したリクエスト情報がリーグＩＤと参加パスワードに該当する場合には、サーバ処理部２０２はそれらをリーグ設定データ５５０と照合する。もし、合致する登録があれば、サーバ処理部２０２は、合致したリーグＩＤ５５０ａを当該プレーヤのチーム設定データ６００の参加リーグＩＤ６１８に設定し、当該リーグのリーグ参加チームリスト５５２に、当該プレーヤのチーム情報を登録・更新して参加登録する。受信したリクエスト情報がメニュー画面への復帰操作に該当する場合には、サーバ処理部２０２はリーグ参加処理を終了する。
【０２０６】
受信したリクエスト情報が「試合」の選択操作に該当する場合には（ステップＳ３７０のＹＥＳ）、サーバ処理部２０２は試合シミュレーション処理を実行する（ステップＳ３７２）。
【０２０７】
図３６〜図３７は、試合シミュレーション処理の流れを説明するためのフローチャートである。同処理において、サーバ処理部２０２は先ず、プレイデータ６５０をサーバ記憶部５０２に新たに生成する。そして、チーム設定データ６００の参加リーグＩＤ６１８を参照し、現在プレーヤのチームが参加しているリーグ参加チームリスト５５２からプレーヤのチームと対戦するチームをランダムに選択し、先攻後攻を自動設定する（ステップＳ３８０）。対戦する２チームのチームＩＤと先攻後攻の情報は、プレイデータ６５０の対戦チーム情報６５２に格納される。
【０２０８】
次いでサーバ処理部２０２は、試合を開始するとともに、試合画像の生成を開始する（ステップＳ３８２）。今現在のイニングと裏／表の識別などの情報は、プレイデータ６５０にイニング情報６５４として記憶される。
【０２０９】
ゲームが開始されたならば、サーバ処理部２０２は、携帯型ゲーム装置１４００へ向けて試合画像とゲーム進行情報（例えば、カウント、進塁情報、得点情報など）とを表示させる為の表示情報の送信を開始する（ステップＳ３８４）。これに伴い、携帯型ゲーム装置１４００では、試合シミュレーション画面Ｗ１４（図８参照）が表示され、試合画面表示部８２に試合の様子が映しだされ、スコアボード８０やカウント表示部８４、進塁状況表示部８６の表示が開始される。
【０２１０】
また、試合が開始されたならば、サーバ処理部２０２は、先ず攻撃チームの打順に従って打者を選択し（ステップＳ３８６）、次いで打者交代処理を実行する（ステップＳ３８８）。打者交代処理は、攻撃に伴うＡＩ処理の一つであり、代打を出すのが適当であるかを判定し、適当な場合に控え要員に登録されている選手から適当な選手を代打として設定する処理を実行する。
【０２１１】
サーバ処理部２０２は、次いで攻撃戦術決定処理を実行する（ステップＳ３９０）。
【０２１２】
図３８は、攻撃戦術決定処理の流れを説明するためのフローチャートである。
同処理において、サーバ処理部２０２は先ず、選手登録リスト６１０を参照し、攻撃チームのうち現在出場中の選手（試合開始当初は、スタメンの設定と同じ。途中交代があれば、交代後のメンバーの意）の適用個人戦術傾向パラメータ６１０ｆ内の攻撃戦術傾向パラメータの項目毎にパラメータ値の合計を算出し、それを攻撃チームの基礎攻撃戦術傾向パラメータ６６０とする（ステップＳ４００）。つまり、所定のメンバー条件を満たす選手の適用個人戦術傾向パラメータ６１０ｆに基づいてチームの基礎的な攻撃戦術の選択傾向を決定し、チームの攻撃能力を変更したことになる。現在出場中の選手としたが、交代要員選手及び控え投手を含めた今回の試合への登録選手全員を所定のメンバー条件として基礎攻撃戦術傾向パラメータ６６０の値を決定することとしてもよい。
【０２１３】
次いで、サーバ処理部２０２は、基礎攻撃戦術傾向パラメータ６６０に、今現在の打者となる選手（攻撃に強い影響を与える主要キャラクタ）の適用個人戦術傾向パラメータ６１０ｆ内の攻撃戦術傾向パラメータをもう一度項目毎に加算して、中間攻撃戦術傾向パラメータ６６４を算出する（ステップＳ４０２）。更に、この中間攻撃戦術傾向パラメータ６６４に、本実施形態における主要キャラクタの一つである監督の適用個人戦術傾向パラメータ６０８ｄ内の攻撃戦術傾向パラメータを項目毎に加算して、今回の打席における最終攻撃戦術傾向パラメータ６６８を決定する（ステップＳ４０４）。
【０２１４】
次に、サーバ処理部２０２は「犠牲バント」の適当条件を満たすかを判定する（ステップＳ４０６）。犠牲バント適当条件テーブル５６０を参照して（図１９参照）、出塁状況５６０ａ毎に定められた犠牲バント適当条件５６０ｂを満たせば（ステップＳ４０６のＹＥＳ）、サーバ処理部２０２は更に犠牲バント選択確率データ５６１（図２０参照）を参照して、最終攻撃戦術傾向パラメータ６６８に応じた選択確率で、犠牲バントの採否を決定する（ステップＳ４０８）。そして、「犠牲バント」が採用されたならば（ステップＳ４１０のＹＥＳ）、今打席の攻撃戦術を「犠牲バント」に設定し（ステップＳ４１２）、攻撃戦術決定処理を終了する。
【０２１５】
犠牲バント適当条件を満たさないと判定された場合（ステップＳ４０６のＮＯ）、又は犠牲バントが採用されなかった場合には（ステップＳ４１０のＮＯ）、サーバ処理部２０２は次ぎにエンドラン適当条件を満たすかを判定する（ステップＳ４２０）。
【０２１６】
エンドラン適当条件テーブル５６２を参照して、出塁状況等に応じて定められたエンドラン適当条件を満たせば（ステップＳ４２０のＹＥＳ）、サーバ処理部２０２は更にエンドラン選択確率テーブル５６３を参照して、最終攻撃戦術傾向パラメータ６６８に応じた選択確率でエンドランの採否を決定する（ステップＳ４２２）。そして、「エンドラン」が採用されたならば（ステップＳ４２４のＹＥＳ）、今打席の攻撃戦術を「エンドラン」に設定し（ステップＳ４２６）、攻撃戦術決定処理を終了する。
【０２１７】
エンドラン適当条件を満たさないと判定された場合（ステップＳ４２０のＮＯ）、又はエンドランが採用されなかった場合には（ステップＳ４２４のＮＯ）、サーバ処理部２０２は次ぎにセーフティバント適当条件を満たすかを判定する（ステップＳ４３０）。
【０２１８】
セーフティバント適当条件テーブル５６４を参照して、打者の打撃能力と走力に基づくセーフティバント適当条件を満たせば（ステップＳ４３０のＹＥＳ）、サーバ処理部２０２は更にセーフティバント選択確率テーブル５６５を参照して、最終攻撃戦術傾向パラメータ６６８に応じた選択確率で、セーフティバントの採否を決定する（ステップＳ４３２）。そして、「セーフティバント」が採用されたならば（ステップＳ４３４のＹＥＳ）、今打席の攻撃戦術を「セーフティバント」に設定し（ステップＳ４３６）、攻撃戦術決定処理を終了する。
【０２１９】
犠牲バント、エンドラン、セーフティバントの何れの適当条件も満たさない場合には、サーバ処理部２０２は通常の打撃による攻撃戦術を選択する（ステップＳ４３８）。
具体的には、通常攻撃戦術選択確率テーブル５６６（図２１参照）で定義されている「早打ち・長打狙い」「遅打ち・長打狙い」「早打ち・単打狙い」「遅打ち・単打狙い」それぞれの選択確率に従って何れかの戦術に決定し、攻撃戦術決定処理を終了する。
【０２２０】
図３６のフローチャートに戻って、サーバ処理部２０２は次に走者交代処理を実行する（ステップＳ４５０）。
走者交代処理は、代走を出した方が良いかを判定するための処理である。例えば、サーバ処理部２０２は先ず、代走適当条件を満たすかを判定する。代走適当条件とは、代走を送るのが適当と考えられる試合状況である。例えば、走者が居て、且つ攻撃チームが負けている又は僅差で勝っている場合などであり、公知の野球ゲームにおける走者交代の発動条件と同様に実現できる。
そして、代走適当条件を満たす場合、プレイデータ６５０の選手パラメータデータ６５６を参照して、現在の走者の中に、走力が所定の基準値を下回る走者の有無を判定する。もし、該当する走者が有る場合には、代走の採否決定処理を実行する。当該処理において代走の採用が選択される確率は、イニングが７回未満では低く、７回以降回を重ねるごとに採用確率が高まるように設定されている。そして、代走が採用された場合には、サーバ処理部２０２は交代要員に登録されている選手を、基準値を下回ると判定された走者の代走に設定する。
【０２２１】
次に、サーバ処理部２０２は、守備交代処理を実行する（ステップＳ４５２）。
守備交代処理は、守備力の強化のために選手交代をするかを判定する処理である。例えば、サーバ処理部２０２は、先ず守備力強化状況条件の一つである守備交代適当条件を満たすかを判定する。守備交代適当条件は、守備交代すべき状況を定義する。例えば、イニングが７回以降で、且つ守備チームが３点以内の点差で勝っていて、且つ打順が１〜３番で有る場合、など守備交代が適当と思われる条件と同様に設定できる。
【０２２２】
そして、守備交代条件を満たすと判定した場合、サーバ処理部２０２は現在守備についている全野手の選手設定データ５２０の守備適性データ５２６を参照し、現在の守備ポジションに対する守備適性値が所定の基準値を下回る野手の有無を判定する。
もし、基準値を下回る野手がいれば、サーバ処理部２０２は守備交代の採否決定処理を実行する。当該処理において守備交代の採用が選択される確率は、イニングが７回未満では低く、７回以降回を重ねるごとに採用確率が高まるように設定されている。そして、守備交代が採用された場合には、サーバ処理部２０２は交代要員に登録されている選手の一人を、先に基準値を下回ると判定された野手と交代させる。
【０２２３】
次いで、サーバ処理部２０２は、守備戦術決定処理を実行する（ステップＳ４５４）。
【０２２４】
図３９は、守備戦術決定処理の流れを説明するためのフローチャートである。
同処理において、サーバ処理部２０２は先ず、守備チームの選手のうち現在試合に出場している選手、つまり控えではない選手の適用個人戦術傾向パラメータ６１０ｆ内の守備戦術傾向パラメータの項目毎にパラメータ値の合計を算出し、それを攻撃チームの基礎守備戦術傾向パラメータ６６２とする（ステップＳ４６２；図２８参照）。つまり、所定のメンバー条件を満たす選手の適用個人戦術傾向パラメータ６１０ｆに基づいてチームの基礎的な守備戦術の選択傾向を決定し、チームの防御能力を変更したことになる。
【０２２５】
次いで、サーバ処理部２０２は、基礎守備戦術傾向パラメータ６６２に、本実施形態における主要キャラクタの一つである現在登板中の投手の適用個人戦術傾向パラメータ６１０ｆ内の守備戦術傾向パラメータをもう一度加算して、中間守備戦術傾向パラメータ６６６を算出する（ステップＳ４６４）。更に、この中間守備戦術傾向パラメータ６６６に本実施形態における主要キャラクタの一つである監督の適用個人戦術傾向パラメータ６０８ｄ内の守備戦術傾向パラメータを項目毎に加算して、今回の打席における最終守備戦術傾向パラメータ６７０を決定する（ステップＳ４６６）。
【０２２６】
次に、サーバ処理部２０２は敬遠選択条件を満たすかを判定する（ステップＳ４６８）。敬遠選択条件テーブル５７０を参照して（図２２参照）、最終守備戦術傾向パラメータ６７０のうち「敬遠」の値５７０ａに対して、打者の打撃能力が所定の適当条件を満たせば（ステップＳ４６８のＹＥＳ）、今打席における守備戦術を「敬遠」に決定し（ステップＳ４７０）、守備戦術決定処理を終了する。
【０２２７】
もし、敬遠選択条件を満たさなければ（ステップＳ４６８のＮＯ）、サーバ処理部２０２は次に最終守備戦術傾向パラメータ６７０に基づく奇襲警戒適当条件を満たすかを判定する（ステップＳ４７２）。
【０２２８】
そして、奇襲警戒適当条件テーブル５７２を参照して（図２３参照）、出塁状況５７２ａと打者の「ミート力」や「走力」といった攻撃関連パラメータとに基づく適当条件５７２ｂを満たす場合（ステップＳ４７２のＹＥＳ）、サーバ処理部２０２は更に奇襲警戒選択確率テーブル５７４を参照して（図２４参照）、最終守備戦術傾向パラメータ６７０の「奇襲警戒」の値と得点差とに基づいて対応づけられた選択確率で、「奇襲警戒」の採否を判定する（ステップＳ４７４）。つまり、状況的には奇襲警戒しても良いが、実際に奇襲警戒策をとるか否かを決定する。
【０２２９】
そして、奇襲警戒が採用された場合には（ステップＳ４７６のＹＥＳ）、サーバ処理部２０２は今回の打者に対する守備戦術を「奇襲警戒」に決定し（ステップＳ４７８）、守備戦術決定処理を終了する。
【０２３０】
一方、そもそも奇襲警戒適当条件を満たさない場合（ステップＳ４７２のＮＯ）、及び採否判定処理で奇襲警戒が採用されなかった場合（ステップＳ４７６のＮＯ）、サーバ処理部２０２は、通常守備戦術選択確率テーブル５７６を参照する（図２３参照）。そして、最終守備戦術傾向パラメータ６７０の「打撃警戒」の値と、「勝負カウント」の値とに基づいて、「早め勝負・長打警戒」「遅め勝負・長打警戒」「早め勝負・短打警戒」「遅め勝負・短打警戒」の何れかの戦術を選択・決定し（ステップＳ４８０）、守備戦術決定処理を終了する。
【０２３１】
図３６の試合シミュレーション処理のフローチャートに戻って、サーバ処理部２０２は次に、打撃パターンデータ５５５を参照し（図１８参照）、先に選択された攻撃戦術に対応する打撃パターンの設定に従って打者を制御する（ステップＳ５００）。より具体的には、現在の投球順５５５ａに対応するジャストミート、標準ミート、打ち損ね、見送りの各確率に従って打撃内容を決定し、決定した打撃内容を実現する動作をさせる。
【０２３２】
次いで、サーバ処理部２０２は、先に選択された攻撃戦術に従って走塁制御をする（ステップＳ５０２）。例えば攻撃戦術として「エンドラン」が選択された場合には、投球と同時に走者を走らせる。
【０２３３】
次いで、サーバ処理部２０２は、守備シフトデータ５５６を参照して、先に選択された守備戦術に対応する守備シフトパターンに従って、野手の守備隊形を制御する（ステップＳ５０４）。
【０２３４】
次いで、投球パターンデータ５５４を参照して（図１７参照）、先に選択された守備戦術に対応する投球パターンの設定に従って投手の投球を制御する（ステップＳ５０６）。具体的には、その時の投球順５５４ｂに対応する勝負球の選択、投球ゾーンの選択、球速の選択、球威の選択の各確率に基づいて、どこにどんな球を投球するか、その投球内容を決定し、それに応じた投球動作制御をする。
【０２３５】
この段階で、攻守両方の行動が決まった事になるので、図３７のフローチャートに移って、サーバ処理部２０２は次に攻守の結果を算出し（ステップＳ５０８）、その結果に応じてカウントや進塁状況、得点などのゲーム進行情報を更新する（ステップＳ５１０）。
【０２３６】
すなわち、試合を自動制御する公知の野球ゲームと同様にして、ストライク及びボールのカウント、飛球の種類とその飛球を捕球できた／できない、敬遠、牽制球のアウト／セーフ、盗塁の成功／失敗、などが決定される。
飛球の種類の判定については、例えば、打撃パターンデータ５５６に基づいて決定された打撃の結果（ジャストミート、標準ミート、打ち損ねの何れか）と、投球パターンデータ５５４に基づいて決定された投球内容との相関関係に、飛球の種類と位置を対応づけたテーブルデータをサーバ記憶部５０２に予め記憶させておいて、これを参照して決定しても良い。勿論、その他の方法でも良い。
【０２３７】
次に、サーバ処理部２０２は、攻守結果によりチェンジになったかを判定する。チェンジにならず（ステップＳ５１２のＮＯ）、打者が進塁していれば（ステップＳ５１４のＹＥＳ）、ステップＳ３９０に戻って、現在の打者に対するシミュレーションが繰り返される。
一方、チェンジにならないが、打者が進塁していなければ（ステップＳ５１４のＮＯ）、ステップＳ３８６に戻って、新たな打者の選択からシミュレーションが繰り返される。
【０２３８】
もし、チェンジになったならば（ステップＳ５１２のＹＥＳ）、サーバ処理部２０２は試合終了条件を満たすかを判定する。試合終了条件を満たさなければ（ステップＳ５１６のＮＯ）、イニング数とその裏表の識別を更新し（ステップＳ５１８）、攻守のチームを反転する（ステップＳ５２０）。そして、サーバ処理部２０２は、攻守反転により守備側になったチームに投手がいるかを判定する。投手がいなければ（ステップＳ５２２のＮＯ）、控え投手リスト６１６に登録されている選手の中から新しい投手を選択して、打順９番の選手と交代し（ステップＳ５２４）、ステップＳ３８６に戻る。
【０２３９】
一方、試合終了条件を満たしていれば（ステップＳ５１６のＹＥＳ）、サーバ処理部２０２は試合画面とゲーム進行情報を携帯型ゲーム装置１４００で表示させる為の表示情報の生成と送信を終了し（ステップＳ５３０）、今回の試合で対戦した両チームの成績を更新して（ステップＳ５３２）、試合シミュレーション処理を終了する。
【０２４０】
図２９のフローチャートに戻って、受信したリクエスト情報が「チャット」機能の選択に該当する場合には（ステップＳ５５０のＹＥＳ）、サーバ処理部２０２はチャット処理を実行して、携帯型ゲーム装置１４００にチャット機能を提供する（ステップＳ５５２）。
【０２４１】
以上、本実施形態によれば、同種のオブジェクト（トレーディングカード３）を手に入れても、重複して登録可能になり、更に重複数に応じて特典が付与される。よって、同種のオブジェクト（トレーディングカード３）を複数枚所有することとなってもそれらのオブジェクト（カード）は無駄にならず、むしろゲームの興趣を高めるように使える。
【０２４２】
〔変形例〕
以上、本発明を適用した第１実施形態について説明したが、本発明を適用可能な形態はこれに限られるものではなく、発明の主旨を逸脱しない限りに於いて、適宜ゲーム内容や、システムや機能の構成要素を追加・省略・変更を行うことができる。
【０２４３】
例えば、上記実施形態では、野球ゲームを例に挙げたが、同種のオブジェクトの複数登録が可能なゲームであれば、サッカーやホッケー、ラグビー、アメリカンフットボール、バレーボールなどその他のスポーツに限られず、チーム対戦のバトル（戦闘）ゲームにも同様に適用できる。またそれに伴い、対戦するチームを決定する母集団は、上記実施形態のようなリーグに限らず、トーナメントなどその他に設定することができるのは勿論である。
【０２４４】
また、上記実施形態では、プレーヤチームの監督について使用登録されたオブジェクトＩＤの使用登録の重複数に基づいて、プレーヤチーム全体のパラメータを変更するようにしたが、監督に限らず、コーチやオーナー等、プレーヤチームに関連するキャラクタについて使用登録されたオブジェクトＩＤの使用登録の重複数に基づいて、プレーヤチーム全体のパラメータを変更するようにしても良い。
【０２４５】
また、上記実施形態では、プレーヤチームの所属選手のパラメータやプレーヤチーム全体のパラメータを主に「能力」として説明したが能力に限られず「体力」であっても良い。
【０２４６】
また、上記実施形態では、ゲームシステムをサーバシステム１１００とプレーヤ端末を含み、ゲーム管理の処理をサーバシステム１１００で実行する構成としたが、サーバシステム１１００とプレーヤ端末とを１台の据え置き型家庭用ゲーム装置或いは業務用ゲーム装置で実現したゲームシステムとしても良い。また、ゲームセンタなどの店舗で本発明のゲームシステムを使用する場合には、プレーヤ端末として業務用ゲーム装置を用いるとしても良い。
【０２４７】
また、上記実施形態では試合する２チーム両方の行動を自動制御する例を挙げたが、守備側チーム及び攻撃側チームの一方のチームをコンピュータ制御させ、他方のチームをプレーヤ自身が制御する構成としても良い。
【０２４８】
また、上記実施形態では、ゲーム内に登場するキャラクタを対応づけたオブジェクトは、それぞれに付与された固有の識別情報がプレーヤにより読取り可能、又はバーコードリーダやＩＣタグリーダなどの装置で読取り可能になっていれば、トレーディングカードに限らずボトルキャップやフィギュア等の玩具や文具などその他の物品でも良く、また、ウェブサイトでの仮想店舗等で購入する仮想のトレーディングカードや玩具等でも良い。この場合にはデータを購入することとなり、カードや玩具は実在しない。
【０２４９】
また、上記実施形態では、オブジェクト（トレーディングカード３）には、それぞれ固有のカードＩＤが設定される構成としたが、選手とシリーズの組み合わせ、つまりオブジェクト（カード）のモデルに応じて固有のカードＩＤが付与された構成としても良い。
【符号の説明】
【０２５０】
２…プレーヤ
３…オブジェクト（トレーディングカード）
８…メニュー選択アイコン表示部
１０…カード番号入力欄
１４…選手情報表示部
１６…登録選手一覧
１８…操作案内表示
２０…スタメン編成タグ
２２…交代要員編成タグ
２４…投手編成タグ
２６…スタメン設定状態表示部
３０…選手アイコン
３４…選手情報表示部
３５…打順指定欄
５２…交代目的選択欄
６０…リーグＩＤ設定欄
６２…参加パスワード設定欄
６６…レギュレーション設定部
７０…リーグＩＤ入力欄
７２…パスワード入力欄
７６…リーグ一覧表示
８２…試合画面表示部
２０２…サーバ処理部
２２０…ゲーム管理部
２２２…カード登録処理部
２２４…チーム編成処理部
２２６…チーム傾向決定部
２２８…戦術決定処理部
２３０…ゲーム進行制御部
２３２…チャット制御部
２３４…リーグ作成処理部
２３６…リーグ参加設定処理部
５００…記憶部
５０６…ゲーム画面表示制御プログラム
５０２…サーバ記憶部
５１２…サーバシステムプログラム
５１４…ゲーム管理プログラム
５１６…ゲーム関連データ
５１８…カード登録データ
５２０…選手設定データ
５２２…攻撃関連パラメータ
５２４…守備関連パラメータ
５２６…守備適性データ
５３０…個人戦術傾向パラメータ
５３２…攻撃戦術傾向パラメータ
５３４…守備戦術傾向パラメータ
５４０…監督設定データ
５５０…リーグ設定データ
５５１…リーグ登録リスト
５５２…リーグ参加チームリスト
５６０…犠牲バント適当条件テーブル
５６１…犠牲バント選択確率テーブル
５６２…エンドラン適当条件テーブル
５６３…エンドラン選択確率テーブル
５６４…セーフティバント適当条件テーブル
５６５…セーフティバント選択確率テーブル
５６６…通常攻撃戦術選択確率テーブル
５７０…敬遠選択条件テーブル
５７２…奇襲警戒適当条件テーブル
５７４…奇襲警戒選択確率テーブル
５７６…通常守備戦術選択確率テーブル
６００…チーム設定データ
６１２…スタメンリスト
６１４…交代要員リスト
６５０…プレイデータ
６６０…基礎攻撃傾向パラメータ
６６２…基礎守備傾向パラメータ
６６４…中間攻撃傾向パラメータ
６６６…中間守備傾向パラメータ
６６８…最終攻撃傾向パラメータ
６７０…最終守備傾向パラメータ
１１００…サーバシステム
１４００…携帯型ゲーム装置
１４５０…制御ユニット
Ｗ２…メニュー画面
Ｗ４…選手登録画面
Ｗ６…チーム編成画面
Ｗ１２…参加リーグ設定画面
Ｗ１４…試合シミュレーション画面
【技術分野】
【０００１】
本発明は、チーム対戦のゲームを実行するための各プレーヤチームの所属選手を管理するコンピュータシステムおよびプログラムに関する。
【背景技術】
【０００２】
チーム対戦型ゲームのジャンルに、プレーヤがチームオーナの立場になって選手を集め、集めた選手の中から自分のチームを編成し、他プレーヤのチームと自動的に試合する様子を観戦するシミュレーションタイプのゲームが知られている。例えば、野球ゲームに関して非特許文献１に開示されている。
【０００３】
この種のジャンルのゲームでは、プレーヤは保有する選手の中から先発選手であるスタメン（スターティングメンバー）を９人選択するなどの編成をする。そして、プレーヤは、自分が編成したチームがどれだけ強いかを他プレーヤとの試合を通じて競って楽しむ。試合中は、各選手の行動はもちろん選手交代やどういった戦術で戦うかも自動で行われるため、プレーヤが試合前の準備で如何に試合状況を予測して編成をするかが腕のみせどころとなる。
【０００４】
また、この種のジャンルのゲームでは、選手集めをトレーディングカードの収集により行わせるものもある。このトレーディングカードには、それぞれゲーム内で使用できる選手が対応づけられており、プレーヤが所定のウェブサイト等でトレーディングカードの使用登録手続きをすることで自チームの編成に使える選手を登録することができる。こうしたゲームは、例えば、非特許文献２に開示されている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】株式会社セガ製オンラインゲーム「プロ野球チームをつくろう！ＯＮＬＩＮＥ２」、[online]、２００８年５月２７日運用開始、インターネット＜ＵＲＬ：http://www.yakyutsuku-online.com/＞
【非特許文献２】株式会社バンダイ製オンラインゲーム「プロ野球オーナーズリーグ」、［online］、２０１０年３月９日β版公開開始、２０１０年３月２０日カード販売開始、インターネット＜ＵＲＬ：http://ownersleague.jp/＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
市販されるトレーディングカードは、通常は中身が見えないようにパッケージされて販売される。その為、プレーヤがトレーディングカードを購入して集めようとすると同じ種類のカードを複数所有することが起きる。
【０００７】
一方、非特許文献２で開示されるゲームに限らず、オブジェクトの使用登録によってゲーム内で使えるキャラクタを管理するゲームでは、同じキャラクタを複数使用できないルールが適用される場合がある。例えば、非特許文献２に開示されたように現実のスポーツを仮想させる設定の場合、トレーディングカードに対応するのは選手であるから、同一選手が複数登場するのはゲームの主旨から外れると見なされるためである。
しかし、プレーヤの心情としては、せっかくオブジェクトを集めたのに同じ種類のオブジェクトがあってもそのうちの１枚しか使えないことになるので、少なからず損した気分となる。ここで、オブジェクトとは、実在のトレーディングカードやフィギュア等の玩具に限られず、仮想的なもの（トレーディングカードや玩具等のデータ）であってもよい。
【０００８】
本発明は、上述した課題に鑑みて為されたものであり、その目的とするところは、オブジェクトに付与されたＩＤの使用登録によってゲーム内で使えるキャラクタを管理するゲームにおいて、重複するキャラクタとなるＩＤでもゲームで利用できるようにして、オブジェクトのコレクションにおける重複所有に伴うネガティブな印象を軽減することである。
【課題を解決するための手段】
【０００９】
以上の課題を解決するための第１の形態は、チーム対戦のゲームを実行するための各プレーヤチームの所属選手を管理するコンピュータシステムであって、
複数の選手それぞれに対応づけて、当該選手に関するオブジェクトを記憶する記憶手段（例えば、図９のサーバ記憶部５０２、図１１のカード登録データ５１８）と、
プレーヤ端末からの操作入力に従って前記オブジェクトＩＤの使用登録要求を受け付ける受付手段（例えば、図９の通信部３７２、サーバ処理部２０２、ゲーム管理部２２０、図３０のステップＳ１０〜Ｓ１２）と、
前記受付手段により受け付けられたオブジェクトＩＤが、既に登録済みであった場合には使用登録を不許可とし、未登録であった場合には使用登録を許可として、各オブジェクトＩＤの使用登録の有無を管理する登録管理手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、カード登録処理部２２２、図１１のカード登録データ５１８、図３０のステップＳ１４〜Ｓ１６）と、
前記登録管理手段により使用登録されたオブジェクトＩＤに対応する選手を、プレーヤチームの所属選手とすることで、各プレーヤチームの所属選手を管理する所属選手管理手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、カード登録処理部２２２、図２６の選手登録リスト６１０、図３０のステップＳ２２）と、
各プレーヤチームについて、当該プレーヤチームの各所属選手について使用登録されたオブジェクトＩＤの使用登録の重複数に基づいて、当該プレーヤチームの所属選手のパラメータ、及び／又は、当該プレーヤチーム全体のパラメータを変更するパラメータ変更処理を実行するパラメータ変更手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、カード登録処理部２２２、チーム編成処理部２２４、図２６の選手登録リスト６１０、図３０のステップＳ３２〜Ｓ３４、図３２のステップＳ２１０）と、を備えたコンピュータシステムである。
【００１０】
また、コンピュータに、各プレーヤチームの所属選手を管理するチーム対戦のゲームを実行するためのプログラムであって、
複数の選手それぞれに対応づけて、当該選手に関するオブジェクトに付与されたオブジェクト固有のＩＤ（以下「オブジェクトＩＤ」という。）を記憶する記憶手段、
プレーヤ端末からの操作入力に従って前記オブジェクトＩＤの使用登録要求を受け付ける受付手段、
前記受付手段により受け付けられたオブジェクトＩＤが、既に登録済みであった場合には使用登録を不許可とし、未登録であった場合には使用登録を許可として、各オブジェクトＩＤの使用登録の有無を管理する登録管理手段、
前記登録管理手段により使用登録されたオブジェクトＩＤに対応する選手を、プレーヤチームの所属選手とすることで、各プレーヤチームの所属選手を管理する所属選手管理手段、
各プレーヤチームについて、当該プレーヤチームの各所属選手について使用登録されたオブジェクトＩＤの使用登録の重複数を用いて、当該プレーヤチームの所属選手のパラメータ、及び／又は、当該プレーヤチームの全体のパラメータを変更するパラメータ変更処理を実行するパラメータ変更手段、
として前記コンピュータを機能させるためのプログラムを構成することとしてもよい。
【００１１】
第１の形態によれば、オブジェクトはオブジェクトＩＤにより使用登録の可否が管理されるとともに、同一選手のオブジェクトについての重複登録をも管理される。そして、使用登録されたオブジェクトに対応する選手がチーム編成に使用可能となり、例えば重複登録された選手のパラメータやチームのパラメータが変更される。
よって、同一選手のオブジェクトを所有してもその内の１枚だけしかゲームで使えないのではなく、その他のオブジェクトもゲームに利用できるようになる。また、オブジェクトのコレクションにおける重複所有に伴うネガティブな印象を軽減するどころか、オブジェクトの重複登録により特典が付与されるというポジティブな作用効果を奏する。
【００１２】
第２の形態は、前記パラメータ変更手段は、当該所属選手についてのオブジェクトＩＤの使用登録の重複数が、当該所属選手に予め定められた重複登録数条件を満たした場合に、当該所属選手のパラメータを変更する第１の手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、カード登録処理部２２２、図２６の選手登録リスト６１０、図３０のステップＳ２８）を有する第１の形態のコンピュータシステムである。
【００１３】
第２の形態によれば、第１の形態と同様の効果を奏するとともに、同一選手のオブジェクトを重複登録した回数がある基準を満たすと特典が付与されるようになるので、同一選手のオブジェクトを重複所有することによるゲームの興趣を与えることができる。
【００１４】
第３の形態は、前記プレーヤ端末からの操作入力に従って、当該プレーヤチームの各所属選手のポジションを設定するポジション設定手段（例えば、図９の通信部３７２、サーバ処理部２０２、ゲーム管理部２２０、チーム編成処理部２２４、図２６の選手登録リスト６１０、図３１のステップＳ１２４〜Ｓ１５４）を更に備え、
前記パラメータ変更手段は、パラメータ変更の判定用として予め定められたポジション条件を満たすポジションに設定された所属選手についてのオブジェクトＩＤの使用登録の重複数に基づいて、当該所属選手のパラメータ、及び／又は、当該プレーヤチーム全体のパラメータを変更する第２の手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、チーム編成処理部２２４、図２６の選手登録リスト６１０、図３３のステップＳ１６２、Ｓ１６６〜Ｓ１７０）を有する、第１又は第２の形態のコンピュータシステムである。
【００１５】
第３の形態によれば、第１又は第２の形態と同様の効果を奏するとともに、重複登録された選手のポジションがある特定の条件を満たすと特典を付与するようにできる。よって、同一選手のオブジェクトを重複所有することによるゲームの興趣を与えることができる。
【００１６】
第４の形態は、前記スポーツゲームは野球ゲームであり、
前記第２の手段は、バッテリーを前記ポジション条件として、投手及び捕手に設定された所属選手についてのオブジェクトＩＤの使用登録の重複数に基づいて、当該所属選手のパラメータ、及び／又は、当該プレーヤチーム全体のパラメータを変更する第３の形態のコンピュータシステムである。
【００１７】
第４の形態は、第３の形態と同様の効果を奏するとともに、重複登録された選手が投手と捕手であるといった限定的な条件を満たす場合に、特典が付与されるようにできる。これによって、同一選手のオブジェクトを重複所有することによるゲームの興趣を与えることができる。
【００１８】
第５の形態は、各選手には、複数のパラメータ項目それぞれに対する標準パラメータ値が定められており、前記パラメータ変更手段は、相対的にパラメータ値が高いパラメータ項目のパラメータ値をより向上させて当該所属選手の特徴をより増長させるように前記パラメータ変更処理を行う第１〜第４の何れかの形態のコンピュータシステムである。
【００１９】
第５の形態によれば、第１〜第４の形態の何れかと同様の効果を奏するとともに、重複登録された選手の特徴が増長されるような特典を付与できる。よって、重複登録の特典をよりゲーム内で感じられるようにできる。
【００２０】
第６の形態は、前記オブジェクトには、同一選手であってもシリーズの異なるオブジェクトが有り、
前記記憶手段は、各選手の各シリーズ毎に、前記オブジェクトＩＤを対応付けて記憶し、
前記パラメータ変更手段は、各所属選手について重複使用登録されたオブジェクトＩＤのシリーズに基づいて前記パラメータ変更処理を実行する第３の手段を有する第１〜第５の何れかの形態のコンピュータシステムである。
【００２１】
第６の形態によれば、第１〜第５の形態の何れかと同様の効果を奏するとともに、同一選手であれば重複登録可能とすることで、重複所有されたオブジェクトの使い道をより多彩にしてより一層ゲームの興趣を高めることができる。
【００２２】
第７の形態は、前記オブジェクトには、監督オブジェクトが含まれており、前記登録管理手段により使用登録されたオブジェクトＩＤが監督カードのオブジェクトＩＤであった場合に、当該監督を当該プレーヤチームの監督に設定するチーム監督管理手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、カード登録処理部２２２、図１４の監督設定データ５４０、図２６の監督登録リスト６０８、図２９のステップＳ５０〜Ｓ５２）と、
各プレーヤチームについて、当該プレーヤチームの監督について使用登録されたオブジェクトＩＤの使用登録の重複数に基づいて、当該プレーヤチーム全体のパラメータを変更するチーム全体パラメータ変更手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、チーム編成処理部２２４、図３４のステップＳ２６０〜Ｓ２６２）と、を更に備えた第１〜第６の何れかの形態のコンピュータシステムである。
【００２３】
第７の形態によれば、第１〜第６の形態の何れかと同様の効果を奏するとともに、監督オブジェクトを重複登録した場合にも特典付与を与えることができるので、オブジェクトの重複所有をより一層ポジティブなものにするとともにゲームの興趣を高めることができる。
【００２４】
第８の形態は、前記ゲームの実行ルールとして前記パラメータ変更手段によるパラメータ変更の是非を設定するパラメータ変更ルール設定手段（例えば、図９のゲーム管理部２２０、リーグ作成処理部２３４、図１５のリーグ設定データ５５０、図３５のリーグ作成処理）を更に備えた、第１〜第７の何れかの形態のコンピュータシステムである。
【００２５】
第８の形態によれば、第１〜第７の形態の何れかと同様の効果を奏するとともに、オブジェクトの重複登録を利用してゲームの実行ルールに多様性を持たせることでゲームの興趣を高めることができる。
【００２６】
第９の形態は、前記所属選手管理手段は、使用登録されたオブジェクトＩＤに対応する選手の他に、前記プレーヤチームの所属選手として、前記オブジェクトＩＤの使用登録無しで事前に自動付与される事前付与選手を管理し、当該事前付与選手と当該使用登録されたオブジェクトＩＤに対応する選手とが同一選手であった場合に、当該事前付与選手を所属選手から除外する事前付与選手管理手段（例えば、図９のサーバ処理部２０２、ゲーム管理部２２０、チーム編成処理部２２４、）を有する、
第１〜第８の何れかの形態のコンピュータシステムである。
【００２７】
第９の形態によれば、例えば、プレーヤチームの構成人数に所属選手が不足する場合に、事前付与選手を自動付与するといった形態が可能となる。事前付与選手は、同一選手に係るオブジェクトＩＤが使用登録された場合には、所属選手から除外されることとなる。
【図面の簡単な説明】
【００２８】
【図１】ゲームシステムの構成例を示す図。
【図２】プレーヤ端末である携帯型ゲーム装置の構成例を説明するための外観図。
【図３】メニュー画面の表示の一例を示す図。
【図４】選手登録の表示の一例を示す図。
【図５】チーム編成画面の表示の一例を示す図。
【図６】リーグ作成画面の表示の一例を示す図。
【図７】参加リーグ設定画面の表示の一例を示す図。
【図８】試合シミュレーション画面の表示の一例を示す図。
【図９】プレーヤ端末である携帯型ゲーム装置と、サーバシステムとの機能構成の一例を示す機能ブロック図。
【図１０】ゲーム関連データのデータ構成の一例を示す図。
【図１１】カード登録データのデータ構成の一例を示す図。
【図１２】選手設定データのデータ構成の一例を示す図。
【図１３】個人戦術傾向パラメータのデータ構成の一例を示す図。
【図１４】監督設定データのデータ構成の一例を示す図。
【図１５】リーグ設定データのデータ構成の一例を示す図。
【図１６】リーグ参加チームリストのデータ構成の一例を示す図。
【図１７】投球パターンデータのデータ構成の一例を示す図。
【図１８】打撃パターンデータのデータ構成の一例を示す図。
【図１９】犠牲バント適当条件テーブルのデータ構成の一例を示す図。
【図２０】犠牲バント選択確率テーブルのデータ構成の一例を示す図。
【図２１】通常攻撃戦術選択確率テーブルのデータ構成の一例を示す図。
【図２２】敬遠選択条件テーブルのデータ構成の一例を示す図。
【図２３】奇襲警戒適当条件テーブルのデータ構成の一例を示す図。
【図２４】奇襲警戒選択確率テーブルのデータ構成の一例を示す図。
【図２５】通常守備戦術選択確率テーブルのデータ構成の一例を示す図。
【図２６】チーム設定データのデータ構成の一例を示す図。
【図２７】スタメンリストのデータ構成の一例を示す図。
【図２８】プレイデータのデータ構成の一例を示す図。
【図２９】サーバシステムにおける主たる処理の流れを説明するためのフローチャート。
【図３０】選手登録処理の流れを説明するためのフローチャート。
【図３１】チーム編成処理の流れを説明するためのフローチャート。
【図３２】図３１より続くフローチャート。
【図３３】指定重複登録処理の流れを説明するためのフローチャート。
【図３４】チームパラメータ変更処理の流れを説明するためのフローチャート。
【図３５】リーグ作成処理の流れを説明するためのフローチャート。
【図３６】試合シミュレーション処理の流れを説明するためのフローチャート。
【図３７】図３６より続くフローチャート。
【図３８】攻撃戦術決定処理の流れを説明するためのフローチャート。
【図３９】守備戦術決定処理の流れを説明するためのフローチャート。
【発明を実施するための形態】
【００２９】
〔第１実施形態〕
本発明を適用した第１実施形態としては、オブジェクトとしてトレーディングカードを用いて選手登録をするシミュレーションタイプの対戦野球ゲームを実行する例について説明する。
【００３０】
［ゲームシステムの構成］
図１は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態は、パソコン１２００や、スマートフォン１３００、携帯型ゲーム装置１４００と言ったプレーヤ端末が、通信回線１を介してコンピュータシステムであるサーバシステム１１００と接続し、ゲーム実行に必要なデータを送受し合うシステムで実現される。
【００３１】
通信回線１は、データ授受が可能な通信路を意味する。すなわち、通信回線１とは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。
【００３２】
サーバシステム１１００は、複数のブレードサーバ１１０２を備えた筐体１１０４と、ブレードサーバ１１０２の管理操作に用いるキーボード１１０６及びディスプレイモニタ１１０８とを備える。ブレードサーバ１１０２は、ＣＰＵやＩ／Ｏモジュール、ＩＣメモリ、ハードディスク等のストレージなどを備え、一台のサーバコンピュータとして機能する。筐体１１０４には、各ブレードサーバ１１０２や、それらに電力を供給する電源モジュール、通信回線１に接続するための通信装置等を搭載する。
【００３３】
そして、本実施形態におけるサーバシステム１１００は、例えばＣＧＩ（Common gateway interface）プログラム実装言語をシステムサポートし、プレーヤ登録手続きや、登録プレーヤの認証（所謂ログイン処理）、野球ゲーム、チャットなどのプレーヤ間のコミュニケーション、といった各種機能をＣＧＩの仕組みを利用して提供する。
【００３４】
尚、サーバシステム１１００は、単独のサーバコンピュータにより実現される構成であっても良いのは勿論である。或いは、据え置き型の家庭用ゲーム装置がサーバ装置としての機能を実現する構成であっても良い。
【００３５】
パソコン１２００や、スマートフォン１３００、携帯型ゲーム装置１４００は、いずれもゲーム画面表示プログラムを実行させることのできるコンピュータである。ゲーム画面表示プログラムとは、サーバシステム１１００から受信した表示情報に基づいて、各種画面を表示する機能や、操作入力に応じたリクエスト情報をサーバシステム１１００へ送信する機能を実現するためのプログラムである。
ゲーム画面表示プログラムは、サーバシステム１１００で生成される表示情報を専用のデータ形式とするならば専用のクライアントプログラムにより実現される。表示情報が、ＨＴＭＬやAdobe Flash（Adobeは登録商標）などを用いてインタラクティブに画像や音声を制御する形式とするならば、汎用のウェブブラウザのプログラムなどでも実現できる。
【００３６】
プレーヤ２は、本実施形態における野球ゲームをプレイするために、事前に野球選手や監督を想起させる意匠を有した専用のオブジェクト（トレーディングカード３）を購入する必要がある。オブジェクト（トレーディングカード３）は、所定枚数を１パッケージとして市販される。このパッケージは、内包されているオブジェクト（トレーディングカード３）の意匠が外からは認識できないようになっている。
【００３７】
オブジェクト（トレーディングカード３）そのものは、監督オブジェクト（監督カード３ａ）と、投手・捕手・野手を含む選手オブジェクト（選手カード３ｂ）との２種類から構成されている。そして、各々には固有の識別情報、オブジェクトＩＤが付与されている。本実施形態では、オブジェクトＩＤとしてオブジェクト番号が印刷されているものとするが、数字以外の文字列でも良いし、バーコードやＱＲコードなどにより実現しても良い。
【００３８】
また、オブジェクト（トレーディングカード３）は、実在の野球リーグの進行状況を反映するように、販売期間ごとに独自のシリーズ（例えば第１弾、第２弾といった各弾のこと。）を構成して供給される。つまり、最新のシリーズ（例えば第２弾）は、現実の野球リーグにおけるその時の出場選手を反映するようにオブジェクト（トレーディングカード３）の種類が編成される。当然、複数のシリーズ（例えば第１弾〜第２弾）に亘って同じ監督や同じ選手に対応するオブジェクト（トレーディングカード３）が含まれる場合もあり得るが、シリーズ違いで同一監督や同一選手のオブジェクト（トレーディングカード３）の意匠は、想起させる監督や選手は変更されないが、画法やポーズ、レイアウトなどに変化がつけられる。換言すると、同じ選手や監督を想起させるオブジェクト（トレーディングカード３）でも、シリーズ違いでモデル（型）が異なるのである。尚、同じ監督や同じ選手のオブジェクト（トレーディングカード３）であっても、シリーズ違いやモデル違いに係わらずに固有のカード番号が付与される点は変わらない。
【００３９】
プレーヤ２は、取得したオブジェクト（トレーディングカード３）を、プレーヤ端末を使って使用登録し、当該オブジェクト（カード）に対応する選手をゲーム内で使用可能にする。そして、使用可能にした選手を使って自分のチームを編成して他プレーヤのチームとリーグ戦を戦う野球ゲームを楽しむ。
【００４０】
［プレーヤ端末の構成］
次に、プレーヤ端末の代表として、携帯型ゲーム装置１４００の構成例について説明する。図２は、本実施形態におけるプレーヤ端末である携帯型ゲーム装置１４００の構成の一例を説明するための外観図である。
【００４１】
携帯型ゲーム装置１４００は、方向入力キー１４０２と、プッシュスイッチ１４０４と、第１液晶ディスプレイ１４０６と、第２液晶ディスプレイ１４０８と、スピーカ１４１０と、イメージセンサ１４３０と、制御ユニット１４５０とを、ヒンジ１４１４で開閉自在な折り畳み型の装置本体１４０１に備えている。そして、第１液晶ディスプレイ１４０６及び第２液晶ディスプレイ１４０８の表示面上には、スタイラスペン１４１６などで触れることによって表示画面の任意位置を接触入力することのできるタッチパネル１４０７、１４０９がそれぞれ装着されている。
【００４２】
また、装置本体１４０１には、コンピュータ読み出し可能な情報記憶媒体であるメモリカード１４４０からデータを読み込んだりデータを書き込みできるメモリカード読取装置１４１８が備えられている。メモリカード１４４０には、携帯型ゲーム装置１４００の制御ユニット１４５０がゲームプレイに係る各種演算処理を実行するために必要なプログラムや各種設定データが記憶されている。その他、装置本体１４０１には図示されていない内蔵バッテリーや電源ボタン、音量調節ボタン等が設けられている。
【００４３】
タッチパネル１４０７、１４０９は、表示画面を遮蔽することなくそれぞれ第１液晶ディスプレイ１４０６及び第２液晶ディスプレイ１４０８の表示画面のほぼ全域を被い、プレーヤがスタイラスペン１４１６（或いは指など）で触れる接触操作を行うと、左上を原点とする直交座標系における接触位置座標を制御ユニット１４５０へ出力することができる。
【００４４】
イメージセンサ１４３０は、ＣＣＤイメージセンサ（Charge Coupled Device Image Sensor）やＣＭＯＳイメージセンサ（Complementary Metal Oxide Semiconductor Image Sensor）などの撮像素子である。オブジェクト（トレーディングカード３）のオブジェクトＩＤ（カードＩＤ）をバーコードやＱＲコードで付与する構成では、これを読み取るための撮影に使用される。
【００４５】
制御ユニット１４５０は、ゲーム装置の制御基板に相当し、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ(Application Specific Integrated Circuit)、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリを搭載する。
【００４６】
また、制御ユニット１４５０は、無線通信モジュール１４１２や、第１液晶ディスプレイ１４０６及び第２液晶ディスプレイ１４０８のドライバ回路、タッチパネル１４０７及びタッチパネル１４０９のドライバ回路、方向入力キー１４０２及びプッシュスイッチ１４０４からの信号を受信する回路、スピーカ１４１０へ音声信号を出力するためのアンプ回路、メモリカード読取装置１４１８への信号入出力回路といった所謂Ｉ／Ｆ回路（インターフェース回路）を搭載する。これら制御ユニット１４５０に搭載されている各要素は、それぞれバス回路を介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。
【００４７】
そして制御ユニット１４５０は、メモリカード読取装置１４１８によってメモリカード１４４０に格納されているプログラムやデータを読み出して、搭載するＩＣメモリにこれらを一時記憶する。そして、読み出したプログラムを実行して演算処理を実行し、方向入力キー１４０２やプッシュスイッチ１４０４、タッチパネル１４０７及び１４０９からの操作入力に応じて携帯型ゲーム装置１４００の各部を制御する。
【００４８】
尚、本実施形態では、携帯型ゲーム装置１４００は必要なプログラムや各種設定データをメモリカード１４４０から読み出す構成としているが、制御ユニット１４５０に搭載されている主要なプログラムやデータをＩＣメモリに予め記憶している構成とすることができる。或いは、無線通信モジュール１４１２を介して、インターネットやＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などの有線／無線の通信回線１に接続し
て外部装置からダウンロードして取得する構成としても良い。
【００４９】
［ゲームの概要］
次に、図３〜図８を参照しながら、本実施形態における野球ゲームの概要について説明する。プレーヤは、先ずプレーヤ端末である携帯型ゲーム装置１４００を起動させて、ゲーム画面表示プログラムを実行させる。次いで、通信回線１を介してサーバシステム１１００に接続して所定のログイン手続きを済ませると、図３に示すようなメニュー画面Ｗ２が表示される。
【００５０】
本実施形態の携帯型ゲーム装置１４００はデュアルディスプレイなので、第１液晶ディスプレイ１４０６にタイトル表示部４とアカウント表示部６とが表示され、第２液晶ディスプレイ１４０８にメニュー選択アイコンが複数並ぶメニュー選択アイコン表示部８が表示される。プレーヤは、スタイラスペン１４１６で所望するメニュー選択アイコンをタッチして選択操作するか、方向入力キー１４０２とプッシュスイッチ１４０４を用いて何れかのアイコンを選択操作する。
【００５１】
本実施形態の野球ゲームを楽しむためには、プレーヤは自身が取得したオブジェクト（トレーディングカード３）を使用登録してゲーム内で使えるようにしなければならない。選手オブジェクト（選手カード３ｂ）の使用登録を、本明細書では「選手登録」と呼び、監督オブジェクト（監督カード３ａ）の使用登録を「監督登録」と呼ぶ。
【００５２】
メニュー選択アイコン表示部８から「選手登録」のアイコンを選択すると、当該操作に対応するリクエスト情報つまりオブジェクト（カード）の使用登録要求が、携帯型ゲーム装置１４００からサーバシステム１１００に送信される。サーバシステム１１００は、このリクエスト情報を受信して、携帯型ゲーム装置１４００に選手画面を表示させるための表示情報を返信する。以下同様に、携帯型ゲーム装置１４００で何らかの操作入力をすると、それに対応するリクエスト情報がサーバシステム１１００に送信され、これを受信したサーバシステム１１００が対応するゲーム管理処理を実行し、新たな表示情報を返信することを繰り返す。
【００５３】
図４は、本実施形態における選手登録画面Ｗ４の一例を示すゲーム画面図であり、同図の上側が上画面、下側が下画面を示す。以降の各画面を示す図面も同様である。
選手登録画面Ｗ４では、新規に登録するオブジェクト（カード）のオブジェクト（カード）番号を入力するオブジェクト（カード）番号入力欄１０と、オブジェクト（カード）番号を入力するためのソフトウェアキーボード１２と、入力されたオブジェクト（カード）に対応する選手についての説明文やパラメータ（能力）値などを表示する選手情報表示部１４と、登録済の選手の選手アイコンが表示される登録選手一覧１６と、操作案内表示１８とが表示される。
【００５４】
プレーヤが、オブジェクト（カード）番号入力欄１０へソフトウェアキーボード１２を使って使用登録したいと思うオブジェクト（トレーディングカード３）のオブジェクト（カード）番号を入力すると、当該オブジェクト（カード）に対応づけられている選手の情報がサーバシステム１１００から返信され、選手情報表示部１４にて表示される。プレーヤは、選手情報表示部１４の内容を確認して、この選手を登録したければ操作案内表示１８に従って所定の登録操作をする。所望するオブジェクト（トレーディングカード３）の登録を済ませ、メニュー画面に戻るメニュー復帰操作をすると、再びメニュー画面Ｗ２に戻ることができる。
【００５５】
選手情報表示部１４には、例えば選手アイコン１４ａや、背番号、選手名、守備位置や投打の左右設定、能力パラメータ値１４ｂ、選手説明文１４ｃ、同一選手重複登録数１４ｄ、特典付与状態マーク１４ｅが表示される。
【００５６】
本実施形態では、同一選手の同種のオブジェクト（トレーディングカード３）を重複して登録することができる。既に選手登録されている選手の元になったオブジェクト（トレーディングカード３）と今回新たに登録するオブジェクト（トレーディングカード３）とが同種である場合、つまり、２つのオブジェクト（トレーディングカード３）に対応付けられている選手が同じでのシリーズも同じである場合、自動的に重複登録扱いとなる。つまり、同じ選手が二人登録されるのではなく、既に登録されている選手に自動的に登録が纏められる。そして、同一選手重複登録数１４ｄは、同じ選手のオブジェクト（カード）を複数枚登録している場合にその合計数を示す。
尚、同じ選手に対応づけられるオブジェクト（トレーディングカード３）でも、シリーズが異なる場合（例えば第１弾と第２弾）、及び／又は、オブジェクト（トレーディングカード３）の意匠が異なる場合、それぞれ別選手として登録される。この例外的処置は、オブジェクト（トレーディングカード３）はシリーズ違いや意匠違いでコレクション性に価値が存在する点に配慮するためであり、必ずしもこれに限る物ではない。
【００５７】
そして、オブジェクト（トレーディングカード３）を重複登録すると、当該オブジェクト（カード）に対応する選手には特典が付与される。特典の内容はゲームの内容に応じて適宜設定可能である。特典付与状態マーク１４ｅは、その選手に特典付与が適用されていることを通知する。尚、本実施形態は野球ゲームなので、選手の競技パラメータが向上するように特典付与が行われるがこれに限らない。例えば、ＲＰＧ（role-playing game）の場合には、アイテムを付与したり、所持金を加算したり、ヒットポイントを回復させる、と言った具合に、ゲームで有利となるように適宜設定することができる。
【００５８】
一方、「監督登録」をするためには、メニュー画面Ｗ２のメニュー選択アイコン表示部８から「監督登録」を選択操作する。すると、選手登録と同様にして監督オブジェクト（監督カード３ａ）を登録し、チーム監督に就任させることができる。登録対象のオブジェクト（カード）と同種オブジェクト（カード）が既に使用登録されている場合には、選手登録と同様に重複登録される。
【００５９】
選手登録及び監督登録を行ったならば、プレーヤは使用可能に登録した選手の中からスタメン（スターティングメンバーの略）、交代要員、控え投手を編成して、自チームを編成する。チーム編成をするためには、メニュー画面Ｗ２のメニュー選択アイコン表示部８から「チーム編成」を選択操作する。
【００６０】
「チーム編成」を選択操作すると、携帯型ゲーム装置１４００では、例えば図５に示すようなチーム編成画面Ｗ６が表示される。チーム編成画面Ｗ６には、スタメンの編成用画面を切換表示させるためのスタメン編成タグ２０、交代要員の編成用画面を切換表示させるための交代要員編成タグ２２、控え投手の編成用画面を切換表示させるための控え投手編成タグ２４が表示される。プレーヤは、編成したい部門に応じたタグを選択する。
【００６１】
スタメン編成タグ２０を選択すると、スタメン設定状態表示部２６が表示される。同表示部では、グラウンドを俯瞰視した略図を背景にして、各守備ポジションに現在登録されている選手の選手アイコン３０が表示される。選手が未登録の守備ポジションについてはブランクのアイコン３２が表示される。
【００６２】
守備ポジションの選択は、スタメン設定状態表示部２６に表示された選手アイコン３０又はブランクアイコン３２をスタイラスペン１４１６によるタッチ操作、又は方向入力キー１４０２及びプッシュスイッチ１４０４を使って選択することで行う。そして、スタメン設定状態表示部２６で何れかのアイコンが選択操作されると、当該アイコンの守備ポジションンが設定対象ポジションとなり、当該守備ポジションに登録されている選手の情報が選手情報表示部３４に表示される。
【００６３】
プレーヤが、設定対象ポジションに既に登録されている選手を外したければ、操作案内表示３８に従って所定の「はずす」操作をする。また、設定対象ポジションに選手を新たに登録したければ、登録選手一覧３６から所望する選手の選手アイコンをタッチして選択する。或いは、登録選手一覧３６から選手アイコンを所望する守備ポジションン位置のアイコンへ、ドラック・アンド・ドロップ操作する。選手情報表示部３４に表示されている選手の打順は、打順指定欄３５で設定できる。
【００６４】
但し、同一選手だがオブジェクト（トレーディングカード３）のシリーズ違いで別々に登録された選手については、その同一選手が既に何れかの守備ポジションに登録されている場合には、登録できないように処理される。つまり、同じ人物が２人存在しないように扱われる。
【００６５】
その一方で、本実施形態では、スタメン設定状態表示部２６が表示された状態において、シリーズ違いのオブジェクト（トレーディングカード３）であるために別々に登録されている同一選手をプレーヤの意思でどれかに纏めて重複登録することができる。
具体的には、登録選手一覧３６の選手アイコンを、同一選手で既に何れかの守備ポジションに登録されている選手アイコン３０へドラック・アンド・ドロップ操作した場合、重複操作された元の選手をドロップ先の守備ポジションに登録されている選手に纏めることができる。つまり、重複操作された元の選手の選手登録が抹消される。但し、本実施形態では、重複操作先の選手、つまり登録が残された側の選手には、選手登録時と同様にして特典が付与される。
尚、スタメン設定状態表示部２６が表示された状態での別の重複操作としては、既に選手が登録されている守備ポジションを選択した状態で、重複操作に対応するボタン操作をしてから登録選手一覧３６の中から、先に選択しておいた守備ポジションに登録されているのと同一選手の選手アイコンを選択するといった方法が考えられる。
【００６６】
チームの編成が完了したならば、プレーヤは自分が編成したチームをどのリーグに参加させるかを決める。参加できるリーグは、自身で作る事もできるし、他プレーヤが既に作成してある中から選ぶこともできる。
【００６７】
メニュー画面Ｗ２のメニュー選択アイコン表示部８において、「リーグ作成」を選択すると、携帯型ゲーム装置１４００では、例えば図６に示すようなリーグ作成画面Ｗ１０が表示される。同画面には、リーグ名を設定するリーグＩＤ設定欄６０と、そのリーグに参加するために必要なパスワードを設定する参加パスワード設定欄６２と、リーグ名やパスワードの文字や数字を入力するためのソフトウェアキーボード６４と、レギュレーション設定部６６と、操作案内表示６８とが表示される。
【００６８】
レギュレーション設定部６６には、当該リーグにおけるレギュレーションの項目と、当該項目の設定内容をプルダウン形式で選択できる項目選択欄との組み合わせが複数表示される。レギュレーション設定部６６において、プレーヤは、リーグ名や参加パスワード、各種レギュレーションの内容を自由に設定できる。本実施形態では、レギュレーションの項目には、「重複登録」の許可／不許可の設定が含まれる。「重複登録」は、リーグ期間中における重複を許可するか否かを設定する。
【００６９】
リーグ名や参加パスワード、各種レギュレーションの内容を設定して、操作案内表示６８に従って所定の登録操作をすると、新しいリーグが登録される。尚、リーグ名とその参加パスワードは、別途、プレーヤが親しい友人に教えることで広めるものとする。つまり、親しい友人同士でリーグを組んでゲームを楽しむ事ができるのである。
【００７０】
メニュー画面Ｗ２のメニュー選択アイコン表示部８において「リーグ参加」を選択すると、携帯型ゲーム装置１４００では、例えば図７に示すような参加リーグ設定画面Ｗ１２が表示される。同画面には、参加を希望するリーグＩＤを入力するためのリーグＩＤ入力欄７０と、参加に必要なパスワードを入力する為のパスワード入力欄７２と、リーグＩＤやパスワードの文字や数字を入力するためのソフトウェアキーボード７４と、登録済のリーグの情報を表示するリーグ一覧表示７６と、操作案内表示７８とが表示される。
【００７１】
プレーヤは、参加希望するリーグ名（本実施形態におけるリーグＩＤ）を、リーグ一覧表示７６で表示されるリーグ名をタッチ操作するなどして選択するか、ソフトウェアキーボード７４を用いて入力する。そして、予め入手しておいたそのリーグの参加パスワードを、ソフトウェアキーボード７４を用いて入力し、操作案内表示７８に従って所定の登録操作をすると、プレーヤのチームが入力したリーグに参加登録される。
【００７２】
チーム編成と参加するリーグの登録を済ませると、プレーヤは自分のチームを他プレーヤのチームと試合させることができるようになる。
【００７３】
メニュー画面Ｗ２のメニュー選択アイコン表示部８において、「試合」を選択すると、サーバシステム１１００では当該プレーヤのチームと、同じリーグの他のチームとの試合のシミュレーション処理（試合の自動制御）が行われ、その結果が随時携帯型ゲーム装置１４００へ送信される。携帯型ゲーム装置１４００では、例えば図８に示すような試合シミュレーション画面Ｗ１４が表示される。
【００７４】
試合シミュレーション画面Ｗ１４には、スコアボード８０と、試合画面表示部８２と、カウント表示部８４と、進塁状況表示部８６と、操作案内表示８８とが表示される。
【００７５】
試合画面表示部８２は、試合の様子を示す画像を表示する。この試合画像は、サーバシステム１１００が試合のシミュレーションを実行して出した試合の進行状況を再現する画像である。試合画像を表示させるための表示情報の生成、及びその表示情報に基づく携帯型ゲーム装置１４００における試合画面の表示に関する処理は、公知のＣＧＩゲームにおけるゲームプレイの画面の表示と同様に実現できる。
プレーヤは、試合シミュレーション画面Ｗ１４で自分が編成したチームの試合ぶりを観戦し、同じリーグに参加する友人とチームの勝敗を競って楽しむ。
【００７６】
［機能ブロックの説明］
次に、本実施形態の機能構成について説明する。
図９は、本実施形態におけるプレーヤ端末である携帯型ゲーム装置１４００と、サーバシステム１１００との機能構成の一例を示す機能ブロック図である。
【００７７】
携帯型ゲーム装置１４００は、操作入力部１００と、処理部２００と、音出力部３５０と、画像表示部３６０と、通信部３７０と、記憶部５００とを備える。
【００７８】
操作入力部１００は、プレーヤによって為された各種の操作入力に応じて操作入力信号を処理部２００に出力する。例えば、プッシュスイッチや、ジョイスティック、タッチパッド、トラックボール、２軸以上の検出軸を有する多軸検出型加速度センサ又は検出軸方向を違えて組み合わされた単軸検出型加速度センサユニット、少なくとも２方向以上の検出方向を有する多方向検出型傾斜センサまたは検出方向を違えて組み合わされた単方向検出型傾斜センサユニット、などによって実現できる。図２の方向入力キー１４０２や、プッシュスイッチ１４０４、３軸加速度センサ１４２２はこれに該当する。
【００７９】
そして、操作入力部１００は、接触位置検出部１０４と撮像部１０６とを含む。
接触位置検出部１０４は、表示画面範囲への接触位置を検出することのできるデバイスで実現される。図２のタッチパネル１４０７，１４０９がこれに該当する。
撮像部１０６は、画像情報を取得する手段であって、例えばＣＣＤイメージセンサやＣＭＯＳイメージセンサによって実現される。図２のイメージセンサ１４３０がこれに当る。
【００８０】
処理部２００は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１００や記憶部５００を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００からの操作入力信号に基づいて各種の演算処理を実行して、携帯型ゲーム装置１４００の動作を制御する。図２の制御ユニット１４５０が処理部２００に該当する。そして、本実施形態における処理部２００は、ゲーム画面表示制御部２１０と、音生成部２５０と、画像生成部２６０と、通信制御部２７０とを備える。
【００８１】
ゲーム画面表示制御部２１０は、サーバシステム１１００から表示情報を受信して、メニュー画面Ｗ２や、選手登録画面Ｗ４、チーム編成画面Ｗ６、リーグ作成画面Ｗ１０、参加リーグ設定画面Ｗ１２及び試合シミュレーション画面Ｗ１４と言った各種ゲーム画面を表示させ、それらのゲーム画面において操作入力部１００へ為された操作に応じてリクエスト情報をサーバシステム１１００へ送信するための各種処理を実行する。
具体的には、ウェブブラウザをベースとして、ＨＴＭＬとともにＪａｖａ（登録商標）やＣＳＳ（Cascading Style Sheets）を利用して能動的に画面表示を制御するウェブ技術や、Adobe Flash（Adobeは登録商標）などの能動的なプラグインを用いて実現できるが、その他の方法でもかまわない。
【００８２】
音生成部２５０は、例えばデジタルシグナルプロセッサ（ＤＳＰ）や、音声合成ＩＣなどのプロセッサ、音声ファイルを再生可能なオーディオコーデック等によって実現され、ゲーム画面表示制御部２１０による処理結果に基づいてゲームに係る効果音やＢＧＭ、各種操作音の音信号を生成し、音出力部３５０に出力する。
【００８３】
音出力部３５０は、音生成部２５０から入力される音信号に基づいて効果音やＢＧＭ等を音出力する装置によって実現される。図２のスピーカ１４１０がこれに該当する。
【００８４】
画像生成部２６０は、例えば、ＧＰＵ、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、ビデオ信号ＩＣ、ビデオコーデックなどのプログラム、フレームバッファ等の描画フレーム用ＩＣメモリ等によって実現される。画像生成部２６０は、ゲーム画面表示制御部２１０による処理結果に基づいて１フレーム時間（例えば１／６０秒）で１枚のゲーム画面を生成し、生成したゲーム画面の画像信号を画像表示部３６０に出力する。
【００８５】
画像表示部３６０は、画像生成部２６０から入力される画像信号に基づいて各種ゲーム画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。
本実施形態では、図２の第１液晶ディスプレイ１４０６及び第２液晶ディスプレイ１４０８がこれに該当する。
【００８６】
通信制御部２７０は、データ通信に係るデータ処理を実行し、通信部３７０を介して外部装置とのデータのやりとりを実現する。
【００８７】
通信部３７０は、通信回線１と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現され、図２の無線通信モジュール１４１２がこれに該当する。
【００８８】
記憶部５００は、処理部２００に携帯型ゲーム装置１４００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームプレイに必要なプログラム、各種データ等を記憶する。また、処理部２００の作業領域として用いられ、処理部２００が各種プログラムに従って実行した演算結果や操作入力部１００から入力される入力データ等を一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図２の制御ユニット１４５０が搭載するＩＣメモリやメモリカード１４４０がこれに該当する。
【００８９】
本実施形態では、記憶部５００はシステムプログラム５０４と、ゲーム画面表示制御プログラム５０６とを記憶している。システムプログラム５０４は、携帯型ゲーム装置１４００のコンピュータとしての入出力の基本機能を実現するためのプログラムである。ゲーム画面表示制御プログラム５０６は、処理部２００が読み出して実行することによってゲーム画面表示制御部２１０としての機能を実現させるためのアプリケーションソフトであるが、システムプログラム５０４の一部として組み込まれた構成であっても良い。
【００９０】
本実施形態におけるサーバシステム１１００は、操作入力部１０２と、サーバ処理部２０２と、画像表示部３６２と、通信部３７２と、サーバ記憶部５０２とを備える。
【００９１】
操作入力部１０２は、サーバの管理のための各種操作を入力するための手段であり、携帯型ゲーム装置１４００の操作入力部１００と同様に実現される。図１のキーボード１１０６がこれに該当する。
【００９２】
サーバ処理部２０２は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１０２やサーバ記憶部５０２を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１０２からの操作入力信号に基づいて各種の演算処理を実行して、サーバシステム１１００の動作を統合的に制御する。そして、本実施形態では、ゲーム管理部２２０と、画像生成部２６２と、通信制御部２７２とを含む。
【００９３】
ゲーム管理部２２０は、各種ゲーム画面をプレーヤ端末で表示させるための表示情報の生成、野球シミュレーションゲームへ参加するプレーヤの情報管理、チームの設定情報の管理、シミュレーションに関する処理等を実行する。
より具体的には、ゲーム管理部２２０は、カード登録処理部２２２と、チーム編成処理部２２４と、チーム傾向決定部２２６と、戦術決定処理部２２８、ゲーム進行制御部２３０と、リーグ作成処理部２３４と、リーグ参加設定処理部２３６とを含む。
【００９４】
カード登録処理部２２２は、オブジェクト（トレーディングカード３（（監督カード３ａ及び選手カード３ｂ）））の使用登録に関する処理を実行し、プレーヤがオブジェクト（カード）に対応するキャラクタをゲーム中で使用可能にする。例えば、選手登録画面Ｗ４（図４参照）の表示情報の生成、オブジェクト（カード）番号の照合、使用登録の可否判定、新たに使用登録されたオブジェクト（カード）に対応する選手のリスト化などを行う。
【００９５】
チーム編成処理部２２４は、チーム編成画面Ｗ６（図５参照）をプレーヤ端末で表示させるための表示情報を生成し、チーム編成画面Ｗ６におけるプレーヤ端末での操作入力に従ってプレーヤのチームを編成する処理を実行する。すなわち、スタメン編成に関する処理と、交代要員編成に関する処理と、控え投手編成に関する処理とを実行する。
【００９６】
チーム傾向決定部２２６は、予め定められた戦術判断要素に関するチーム全体としての傾向を決定する。本実施形態では、所定のメンバー条件（スタメンに登録）を満たす選手の個人戦術傾向パラメータ５３０（図１３参照）に基づいてチーム全体の攻守それぞれの戦術選択傾向を示す「基礎攻撃戦術傾向パラメータ」と「基礎守備戦術傾向パラメータ」を算出する。
【００９７】
戦術決定処理部２２８は、対戦の自動制御を実現する機能部の一つであって、攻守それぞれにおける戦術をチーム全体の戦術判断要素に関する傾向に基づいて決定する。
具体的には、チーム全体の戦術判断要素に関する傾向（「基礎攻撃戦術傾向パラメータ」と「基礎守備戦術傾向パラメータ」）と、チームの主要キャラクタ（本実施形態では、投手、打者、監督。つまり場面場面の戦術選択に強く影響を与えるキャラクタ）に定められた傾向と、試合の進行状況とに基づいて、攻撃戦術および守備戦術を決定する。
【００９８】
より具体的には、攻撃または守備の基礎攻撃戦術パラメータに、その時の戦術決定に影響を与える選手（本実施形態では、投手、打者）の個人戦術傾向パラメータ５３０を加算して、「中間攻撃傾向パラメータ」「中間守備傾向パラメータ」を算出し、更に監督の個人戦術傾向パラメータ５３０を加算して、最終的に戦術選択時に供される戦術傾向パラメータ（「最終攻撃戦術傾向パラメータ」と「最終守備戦術傾向パラメータ」）を算出する。これらの戦術傾向パラメータは、ゲーム関連データ５１６に格納される。
【００９９】
ゲーム進行制御部２３０は、対戦の自動制御を実現する機能部の一つであって、主に野球の試合のシミュレーション処理を実行する。すなわち、プレーヤのチームを構成する選手、および他チームを構成する選手それぞれを所定のＡＩ制御で制御してそれぞれの行動を決定し、野球の試合をシミュレーションする。そして、シミュレーションした試合画像をプレーヤ端末で表示させるための表示情報を生成する。
【０１００】
チャット制御部２３２は、プレーヤ間でのコミュニケーション手段の１つとしてチャット機能を提供するための処理を実行する。
【０１０１】
リーグ作成処理部２３４は、プレーヤの操作入力に基づいて、対戦するチームを選択するための母集団の枠組みの作成に関する処理を実行する。具体的には、リーグの名称などのＩＤと、当該母集団へ参加するための条件（パスワードを含む）と、その母集団から選ばれたチームの対戦に適用されるレギュレーションとを設定するための処理を実行する。より具体的には、リーグ作成画面Ｗ１０の表示情報の生成、同画面における操作入力に基づいて、リーグ設定情報をサーバ記憶部５０２に記憶させる処理を行う。尚、対戦形式がリーグ方式ではなく、トーナメント方式の場合には、母集団はトーナメントとする。
【０１０２】
リーグ参加設定処理部２３６は、プレーヤが作成したチームをリーグ作成処理部２３４で作成された母集団へ参加させるための手続き処理を行う。具体的には、参加リーグ設定画面Ｗ１２（図７参照）をプレーヤ端末で表示させるための表示情報を生成し、同画面における操作入力に基づいて参加登録の処理をする。
【０１０３】
画像生成部２６２は、サーバシステム１１００の保守に関する画像を生成し、画像表示部３６２へ出力する。試合画面の表示情報として静止画や動画の情報を送信する場合に、それらを生成する機能を持たせても良い。
【０１０４】
画像表示部３６２は、画像生成部２６２から入力される画像信号に基づいてシステム管理のための各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図１のディスプレイモニタ１１０８がこれに該当する。
【０１０５】
通信制御部２７２は、データ通信に係るデータ処理を実行し、通信部３７２を介して外部装置とのデータのやりとりを実現する。
【０１０６】
通信部３７２は、通信回線１と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。
【０１０７】
サーバ記憶部５０２は、サーバ処理部２０２にサーバシステム１１００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームを管理するために必要なプログラム、各種データ等を記憶する。また、サーバ処理部２０２の作業領域として用いられ、サーバ処理部２０２が各種プログラムに従って実行した演算結果など一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図１ではブレードサーバ１１０２が搭載するＩＣメモリやハードディスクなどの情報記憶媒体がこれに該当する。
そして、本実施形態のサーバ記憶部５０２は、サーバシステムプログラム５１２と、ゲーム管理プログラム５１４と、ゲーム関連データ５１６とを記憶する。
【０１０８】
サーバシステムプログラム５１２は、サーバ処理部２０２が読み出して実行することでサーバシステム１１００に必要な基本的な入出力機能を実現する為のシステムプログラムである。ゲーム管理プログラム５１４は、サーバ処理部２０２が読み出して実行することで、ゲーム管理部２２０としての機能を実現させる為のプログラムである。
【０１０９】
図１０はゲーム関連データ５１６の一例を示す図である。ゲーム関連データ５１６は、カードの登録及びゲーム内に登場するキャラクタの初期設定に関する情報として、カード登録データ５１８と、複数の選手設定データ５２０と、複数のレンタル選手設定データ５３６と、複数の監督設定データ５４０と、を記憶する。
【０１１０】
また、リーグに関する情報として、リーグ設定データ５５０と、リーグ登録リスト５５１と、リーグ参加チームリスト５５２とを記憶する。
【０１１１】
また、試合のシミュレーションをする際に、各種攻撃戦術や守備戦術に対応した選手の具体的な行動を決定するための情報として、投球パターンデータ５５４と、打撃パターンデータ５５５と、守備シフトデータ５５６とを記憶する。
【０１１２】
また、試合のシミュレーションをする際に、攻撃チームの攻撃戦術を選択するための情報として、犠牲バント適当条件テーブル５６０と、犠牲バント選択確率テーブル５６１と、エンドラン適当条件テーブル５６２と、エンドラン選択確率テーブル５６３と、セーフティバント適当条件テーブル５６４と、セーフティバント選択確率テーブル５６５と、通常攻撃戦術選択確率テーブル５６６と、を記憶する。
【０１１３】
また、試合のシミュレーションをする際に、守備関連パラメータの守備戦術を選択するための情報として、敬遠選択条件テーブル５７０と、奇襲警戒適当条件テーブル５７２と、奇襲警戒選択確率テーブル５７４と、通常守備戦術選択確率テーブル５７６と、を記憶する。
【０１１４】
また、プレーヤが設定したチームに関する情報を格納する複数のチーム設定データ６００と、ゲームプレイに伴って随時生成・更新される情報を格納するプレイデータ６５０とを記憶する。その他、ゲームの管理制御に必要な、タイマ、カウンタ、フラグ、ログインしている携帯型ゲーム装置１４００のＩＰアドレスなどのデータ通信に必要な各種情報を適宜記憶するものとする。
【０１１５】
では、各データについて個別に詳細な説明をする。
カード登録データ５１８は、市販されているオブジェクト（トレーディングカード３）に割り当てられた各種情報を格納する。例えば、図１１に示すように、オブジェクト（トレーディングカード３）それぞれに固有に付与されているオブジェクト（カード）番号５１８ａと、当該番号に対応づけられる選手の識別情報である選手ＩＤ５１８ｂ（監督の場合には監督ＩＤに相当）と、販売シリーズの識別情報を格納するシリーズＩＤ５１８ｃと、使用済フラグ５１８ｄとを対応付けて記憶する。使用済フラグ５１８ｄは、「１」で当該オブジェクト（カード）が選手登録や監督登録に使用済で有ることを示し、「０」で未使用を示す。
【０１１６】
選手設定データ５２０は、野手，捕手，投手といった各種選手の種類を定義する情報であって、本実施形態の野球ゲームに登場する選手の種類だけ予め用意されている。
一つの選手設定データ５２０は、例えば、図１２に示すように、選手の名前などの識別情報を格納する選手ＩＤ５２０ａと、チーム編成画面Ｗ６（図５参照）などで表示される選手アイコン３０を表示させるための選手アイコンデータ５２０ｂと、試合画面表示部８２（図８参照）で野球をプレイする選手を表示させるための選手モデルデータ５２０ｃや選手テクスチャデータ５２０ｄ及び選手モーションデータ５２０ｅを記憶する。
【０１１７】
また、当該選手の特殊技能５２０ｆと、選手説明文５２０ｇと、実チームＩＤ５２０ｈとを記憶する。
【０１１８】
特殊技能５２０ｆは、特定の発動条件と、発動条件を満たした時に適用される当該選手固有の処理を定義した情報である。発動条件は、試合状況を示す各種パラメータ値（例えば、イニング数、アウトカウント、打順、ストライクやボールのカウント、進塁状況などを示す数値）で定義される。適用される処理は、例えば能力パラメータ値の増減値として定義される。
選手説明文５２０ｇは、選手登録画面Ｗ４や、チーム編成画面Ｗ６などの選手情報表示部１４，３４に表示されるテキスト情報を格納する）。
実チームＩＤ５２０ｈは、当該選手が現実の野球リーグにおいて所属するチームを識別する情報を格納する。
【０１１９】
また、選手設定データ５２０は、当該選手固有の能力や適性、行動傾向に関する情報として、攻撃関連パラメータ５２２と、守備関連パラメータ値５２４と、守備適性データ５２６と、個人戦術傾向パラメータ５３０とを記憶する。
【０１２０】
攻撃関連パラメータ５２２は、当該選手の打撃や走塁などの攻撃時の能力を定義する。例えば、安打率、長打力、ミート力、走力などのパラメータの値を適宜設定する。
守備関連パラメータ５２４は、当該選手の投球や守備などの守備時の能力を定義する。例えば、肩の強さ、制球力、最大球速、勝負球種（所謂決め球）などのパラメータの値を適宜設定する。
守備適性データ５２６は、当該選手がどこの守備ポジションに適性が有るかを示す情報であって、守備ポジション毎に守備適性値（０：適性無し〜１００：適性最大）を対応づけて格納する。
【０１２１】
個人戦術傾向パラメータ５３０は、プレイ中の打撃や走塁などの攻撃行動や守備行動にどういった行動を選択する傾向があるかの個人の好みを表す情報を格納する。例えば、図１３に示すように、攻撃戦術傾向パラメータ５３２と、守備戦術傾向パラメータ５３４とを格納する。
【０１２２】
攻撃戦術傾向パラメータ５３２は、例えば（１）数値が大きいほどカウントの早いうちから打ちに出る（打撃を試みる）傾向を示す「早打ち」、（２）数値が高いほど長打狙いを好むことを示す「長打」、（３）数値が大きいほどバント成功率が高いことを示す「バント」、（４）数値が大きいほど積極的に盗塁を狙う傾向を示す「走塁」、（５）数値が高いほど攻撃的なプレイを好む傾向、及び試合の序盤、中盤、終盤などの試合進行時期が後方になる程より積極的に攻撃に臨む傾向を示す「攻撃スタイル」、といったパラメータの項目とパラメータの値とを対応づけて格納する。パラメータの項目は、ゲーム内容などに応じて適宜設定できるのは言うまでも無い。
【０１２３】
守備戦術傾向パラメータ５３４は、例えば、（１）数値が大きいほどカウントの早い段階で勝負に出る傾向を示す「勝負カウント」、（２）数値が大きいほど打者の長打を警戒する傾向を示す「打撃警戒」、（３）数値が大きいほどセーフティバントやエンドラン、スクイズなどの奇襲を警戒する傾向を示す「奇襲警戒」、（４）数値が大きいほど敬遠策への許容が高いことを示す「敬遠」、（５）数値が高いほど手堅い守備を好む傾向、及び試合の序盤、中盤、終盤などの試合進行時期が後方になる程より厳重に守備に臨む傾向を示すことを示す「守備スタイル」、といったパラメータの項目とパラメータの値とを対応づけて格納する。パラメータの項目は、ゲーム内容などに応じて適宜設定できるのは言うまでも無い。
【０１２４】
尚、本実施形態では、攻撃戦術傾向パラメータ５３２及び守備戦術傾向パラメータ５３４は、基本的には中庸を示す「０」を格納するが、ゲームメーキングに影響を与える特定の選手（例えば、３冠王やゴールデングラブ賞を採るような高い能力を有する野手、投手、捕手）が−２〜＋２の間の数値を有し、スタメン全員のパラメータ値を合計しても−５〜＋５の間に収まるように、プラス値とマイナス値が適当に分散されて設定されている。勿論、これに限らず、全ての選手の全てのパラメータに適当な数値をばらけて設定する構成でも良い。
【０１２５】
レンタル選手設定データ５３６は、プレーヤが取得したオブジェクト（カード）が出場メンバー数に満たない場合に、自動的に貸し付けられる選手の設定データを格納する。データ構成は、基本的に選手設定データ５２０と同様に実現できる。但し、レンタル選手に付与される選手ＩＤは、レンタル選手固有とされる。つまり、オブジェクト（トレーディングカード３）に対応づけられている選手と、レンタル選手が仮に同一人物であったとしても、選手ＩＤは異なるので別キャラクタとして扱われることとなる。また、オブジェクト（トレーディングカード３）の購入意欲を減退させないために、レンタル選手は各種パラメータにおいて選手設定データ５２０で設定される正規の選手より劣るように設定されている。
【０１２６】
監督設定データ５４０は、選手についての選手設定データ５２０に相当するデータであって、監督についての各種設定情報を格納する。そして、ゲーム中に登場する監督の種類だけ予め用意される。
具体的には、例えば図１４に示すように、監督の名前などの識別情報を格納する監督ＩＤ５４０ａと、監督のオブジェクト（カード）登録のための画面などで表示される監督アイコンデータ５４０ｂと、特殊技能５４０ｆと、監督説明文５４０ｇと、実チームＩＤ５４０ｈと、個人戦術傾向パラメータ５４２とを含む。個人戦術傾向パラメータ５４２は、選手設定データ５２０のそれと同様に、攻撃戦術傾向パラメータ５４４と守備戦術傾向パラメータ５４６とを含む。
【０１２７】
リーグ設定データ５５０は、プレーヤが作成したリーグの設定情報を格納するデータであり、作成されたリーグ毎に用意される。本実施形態では、例えば図１５に示すように、リーグの名称などの識別情報を格納するリーグＩＤ５５０ａと、参加パスワード５５０ｂと、レギュレーション設定データ５５０ｃとを含む。レギュレーション設定データ５５０ｃは、レギュレーションの項目毎に設定内容を対応付けて格納する。
【０１２８】
リーグ登録リスト５５１は、プレーヤにより作成された全てのリーグのリストであって、リーグＩＤと参加パスワードとを対応づけて格納する。
【０１２９】
リーグ参加チームリスト５５２は、各リーグに現在参加しているチームの情報を格納するデータセットであって、対応するリーグ毎に用意される。一つのリーグ参加チームリスト５５２には、例えば図１６に示すように、対応するリーグＩＤを格納する対応リーグＩＤ５５２ａと、参加チームＩＤ５５２ｂに対応付けられたチーム成績５５２ｃとが格納される。
【０１３０】
投球パターンデータ５５４は、１打席における配球内容を決定するための基礎情報であって、守備戦術の種類に応じた数だけ予め用意される。
例えば、図１７に示すように、バント対応パターン、エンドラン対応パターン、「早め勝負・長打警戒」対応パターン・・・と言った具合に各種投球パターンが用意されている。一つの投球パターン５５４ａは、投球順５５４ｂ毎に、勝負球（決め球）選択確率５５４ｃと、投球ゾーン別選択確率５５４ｄと、球速選択確率５５４ｅと、球威選択確率５５４ｆとが対応付けて格納されている。投球内容は、これらの確率に基づく抽選で決定される。
【０１３１】
打撃パターンデータ５５５は、１打席においてどのように打撃をするかを決定するための基礎情報であって、攻撃戦術の種類に応じた数だけ予め用意される。
本実施形態では、例えば図１８に示すように、犠牲バント対応パターン、ヒットエンドラン対応パターン、「早打ち・長打狙い」対応パターン、・・・と言った具合に用意される。そして、一つの対応パターンは、投球順５５５ａと対応づけて、ジャストミート確率５５５ｂと、標準ミート確率５５５ｃと、打ち損ね確率５５５ｄと、見送り確率５５５ｅとが格納されている。打撃内容は、これらの確率に基づく抽選で決定される。
勿論、打撃パターンの設定の仕方はこれに限らず、スイングの是非、スイングの位置（内角高め、内角中央、内角低め、外角高め、外角中央、外角低め、中央）、スイングタイミングのジャストミート／遅い／早い、と言った項目の各確率を格納するとしても良い。
【０１３２】
守備シフトデータ５５６は、守備戦術の種類に応じて各守備ポジションの守備位置を決定する為のデータであって、守備戦術毎に標準の守備位置に対する相対位置を格納する。
【０１３３】
犠牲バント適当条件テーブル５６０は、攻撃戦術「犠牲バント」を選択するのが適当とする条件を定義する。例えば、図１９に示すように、出塁状況５６０ａと対応づけて、打者の「ミート力」や「走力」などの攻撃関連パラメータ値５２２をファクタとする適当条件５６０ｂを格納する。
【０１３４】
犠牲バント選択確率テーブル５６１は、攻撃戦術「犠牲バント」が適当と判断される場合に、実際に犠牲バントが選択される確率を定義する。例えば、図２０に示すように、最終攻撃戦術傾向パラメータの「バント」の値５６１ａと、攻撃チーム側から見た得点差５６１ｂとの相関関係で選択確率を格納する。
【０１３５】
エンドラン適当条件テーブル５６２は、攻撃戦術「エンドラン（ヒットエンドランの略）」を選択するのが適当とする条件を定義する。データ構成は、犠牲バント適当条件テーブル５６０と同様に実現できる。すなわち、適当条件５６０ｂのファクタとする攻撃側のパラメータを、例えば打者の「ミート力」と走者の「走力」に置き換えれば良い。
【０１３６】
エンドラン選択確率テーブル５６３は、攻撃戦術「エンドラン」が適当と判断される場合に、実際にエンドランが選択される確率を定義する。データ構成は、犠牲バント選択確率テーブル５６１における「バント」の値を、最終攻撃戦術傾向パラメータの「走塁」の値に置き換えることで同様に実現できる。
【０１３７】
セーフティバント適当条件テーブル５６４は、攻撃戦術「セーフティバント」を選択するのが適当とされる条件を定義する。本実施形態では、打者の「ミート力」と「走力」がともに所定の基準値を超えていることを適合条件とする。勿論、打者の「ミート力」と「走力」との相関関係に基づいて適当条件を満たす確率を定義しても良い。
【０１３８】
セーフティバント選択条件テーブル５６５は、セーフティバントが適当と判断される場合に、実際にセーフティバントが選択される確率を定義する。犠牲バント選択確率テーブル５６１と同様に、最終攻撃戦術傾向パラメータの「バント」の値と、攻撃チーム側から見た得点差とのマトリクスで選択確率を格納する。
【０１３９】
攻撃戦術選択確率テーブル５６６は、ヒッティングの戦術を選択する確率を定義する。本実施形態では、「早打ち・長打狙い」「遅打ち・長打狙い」「早打ち・短打狙い」「遅打ち・短打狙い」の４種の戦術が選択可能である。当該テーブルでは、図２１に示すように、最終攻撃戦術傾向パラメータの「長打」の値５６６ａと、「早打ち」の値５６６ｂとの相関関係に基づいて、４種の戦術それぞれの選択確率を格納する。
【０１４０】
敬遠選択条件テーブル５７０は、守備戦術「敬遠」が選択される条件を定義する。本実施形態では、図２２に示すように、最終守備戦術傾向パラメータの「敬遠」の値５７０ａと、打者の「ミート力」及び「長打力」の合計５７０ｂとの相関関係に基づいて、選択される確率を格納する。
【０１４１】
奇襲警戒適当条件テーブル５７２は、守備戦術「奇襲警戒」、つまりセーフティバントやエンドランを警戒した戦術を選択するのが適当とする条件を定義する。例えば、図２３に示すように、出塁状況５７２ａの条件別に、打者の「ミート力」と「走力」をファクタとする適当条件５７２ｂを格納する。
【０１４２】
奇襲警戒選択確率テーブル５７４は、奇襲警戒が適当と判断される場合に、実際に奇襲警戒が選択される確率を定義する。例えば、図２４に示すように、最終守備戦術傾向パラメータの「奇襲警戒」の値５７４ａと、守備チーム側を主観とした得点差５７４ｂとの相関関係に基づいて選択される確率を格納する。
【０１４３】
通常守備戦術選択確率テーブル５７６は、ピッチングの戦術を選択する確率を定義する。本実施形態では、「早め勝負・長打警戒」「遅め勝負・長打警戒」「早め勝負・短打警戒」「遅め勝負・短打警戒」の４種から選択可能である。そして、例えば図２５に示すように、最終守備戦術傾向パラメータの「打撃警戒」の値５７６ａと、最終守備戦術傾向パラメータの「勝負カウント」の値５７６ｂとの相関関係に基づいて、上記４種の守備戦術別の選択確率を格納する。
【０１４４】
チーム設定データ６００は、プレーヤ毎に用意され、プレーヤが作成したチームの情報を格納する。例えば、図２６に示すように、プレーヤＩＤ６０２と、パスワード６０４と、チームＩＤ６０６と、監督登録リスト６０８と、選手登録リスト６１０と、スタメンリスト６１２と、交代要員リスト６１４と、控え投手リスト６１６と、参加リーグＩＤ６１８と、を含む。
【０１４５】
監督登録リスト６０８は、当該プレーヤが既に登録した監督の情報が格納される。例えば、どのオブジェクト（トレーディングカード３）の監督オブジェクト（カード３ａ）が登録されたかを示す情報として、そのオブジェクト（カード）に対応する監督ＩＤ６０８ａと、シリーズＩＤ６０８ｂとを格納する。また、同種オブジェクト（カード）が重複して登録された回数を示す同一監督重複登録数６０８ｃと、適用個人戦術傾向パラメータ６０８ｄとを格納する。
新規に登録される場合には、適用個人戦術傾向パラメータ６０８ｄには監督設定データ５４０の個人戦術傾向パラメータ５４２がコピーされ、同種カードの重複登録に伴う特典の付与として、パラメータ値が「０」以外のパラメータ値が所定値加算されて更新される。つまり、その監督の戦術傾向がより際だつようになる。
【０１４６】
選手登録リスト６１０は、当該プレーヤが既に登録しているオブジェクト（カード）に対応する選手の情報が格納されているデータセットが複数格納されている。一つのデータセットには、どのオブジェクト（トレーディングカード３）の選手オブジェクト（カード３ｂ）が登録されたかを示す情報として選手ＩＤ６１０ａとシリーズＩＤ６１０ｂとが含まれる。また、同一選手重複登録数６１０ｃと、適用攻撃関連パラメータ６１０ｄと、適用守備関連パラメータ６１０ｅと、適用個人戦術傾向パラメータ６１０ｆとが含まれる。
【０１４７】
シリーズＩＤ６１０ｂは、登録選手に対応づけられたオブジェクト（トレーディングカード３）の販売シリーズの識別情報である。新規登録される場合には、オブジェクト（カード）登録データ５１８（図１１参照）のシリーズＩＤ５１８ｃがコピーされる。
同一選手重複登録数６１０ｃは、同種のオブジェクト（カード）が何回登録されたかを示す。当然、新規に登録される場合には「１」に設定され、同種のカードが登録操作される都度「１」加算される。
【０１４８】
適用攻撃関連パラメータ６１０ｄと適用守備関連パラメータ６１０ｅは、それぞれ当該選手に試合のシミュレーション処理において適用される攻撃力及び守備力に関する各種パラメータ値を格納する。新規に登録される場合には、当該選手に対応する選手設定データ５２０（図１２参照）の攻撃関連パラメータ５２２及び守備関連パラメータ５２４がそのまま格納される。そして、同じオブジェクト（カード）が複数回登録されると、その回数に応じて特典として加算補正される。
【０１４９】
適用個人戦術傾向パラメータ値６１０ｆは、どういった攻撃や守備をするかその傾向に関する各種パラメータ値を格納する。新規に登録される場合には、当該選手に対応する選手設定データ５２０の個人戦術傾向パラメータ値５３０がコピーされる。そして、チーム能力に関する特典付与の一つとして変更され、試合のシミュレーション処理において適用される。本実施形態では、チーム編成されている選手の適用個人戦術傾向パラメータ６１０ｆに基づいてチームの戦術傾向パラメータを決定するので、適用個人戦術傾向パラメータ６１０ｆの変更はチームのパラメータの一部を変更することにほかならない。
【０１５０】
スタメンリスト６１２は、スターティングメンバーとした登録した選手の守備ポジションと、打順などの情報を格納する。例えば、図２７に示すように、スタメンリスト６１２は、守備のポジション６１２ａ毎に、当該ポジションに割り当てられた選手の選手ＩＤ６１２ｂと、打順６１２ｃとを対応付けて格納する。
【０１５１】
交代要員リスト６１４は、交代要員として登録した選手と、交代目的の設定情報を格納する。
控え投手リスト６１６は、控え投手として登録された選手の選手ＩＤと対応づけて、「中継ぎ」や「抑え」といった交代目的を示す情報が格納されている。
参加リーグＩＤ６１８は、当該チームが現在参加しているリーグＩＤを格納する。
【０１５２】
プレイデータ６５０は、試合毎に生成され、試合状況を示す情報や、試合を制御する為の各種情報を格納する。例えば、図２８に示すように、試合する２チームのチームＩＤ等を格納する対戦チーム情報６５２と、現在のイニング数とその表裏の識別情報を格納するイニング情報６５４と、試合に参加している全選手の各種パラメータを選手ＩＤと対応づけて格納する選手パラメータデータ６５６と、交代要員や控え投手の内すでに交代が行われた選手の選手ＩＤを格納する交代済選手リスト６５８と、基礎攻撃傾向パラメータ６６０と、基礎守備傾向パラメータ６６２と、中間攻撃傾向パラメータ６６４と、中間守備傾向パラメータ６６６と、最終攻撃傾向パラメータ６６８と、最終守備傾向パラメータ６７０とを格納する。
【０１５３】
［動作の説明］
次に、本実施形態におけるサーバシステム１１００の動作について説明する。尚、既にユーザ登録を済ませたプレーヤが、適宜携帯型ゲーム装置１４００を使ってログインした状態にあるものとする。
【０１５４】
図２９は、サーバシステム１１００の本実施形態における主たる処理の流れを説明するためのフローチャートである。
サーバシステム１１００のサーバ処理部２０２は、先ず携帯型ゲーム装置１４００へメニュー画面Ｗ２を表示させるための表示情報を送信する（ステップＳ２）。
表示情報は、例えば携帯型ゲーム装置１４００の画像表示に用いるプログラムがウェブブラウザであれば、ＨＴＭＬ情報などである。携帯型ゲーム装置１４００にて何らかの操作入力が行われると、サーバシステム１１００へ操作入力に応じたリクエスト情報が送信される。
【０１５５】
受信したリクエスト情報から、携帯型ゲーム装置１４００にて野手及び投手を登録するための「選手登録」が選択されたと判定される場合（ステップＳ４のＹＥＳ）、サーバ処理部２０２は選手登録処理を実行する（ステップＳ６）。
【０１５６】
図３０は、本実施形態における選手登録処理の流れを説明するためのフローチャートである。同処理において、サーバ処理部２０２は先ず、携帯型ゲーム装置１４００へ選手登録画面Ｗ４（図４参照）を表示させるための情報、より具体的にはカード番号入力欄１０と、番号入力用のソフトウェアキーボード１２とを表示させるための表示情報やＪａｖａ（登録商標）プログラム、及び当該プレーヤが登録している登録選手一覧１６を表示させる為のＣＧＩソースなどを携帯型ゲーム装置１４００へ送信する（ステップＳ１０）。
携帯型ゲーム装置１４００で、オブジェクト（カード）番号入力欄１０に番号が入力され登録操作すると、ソフトウェアキーボード１２への操作入力情報に基づいたオブジェクト（カード）番号とともに、そのオブジェクト（カード）の使用登録要求となるリクエスト情報がサーバシステム１１００へ送信される。
【０１５７】
サーバ処理部２０２は、携帯型ゲーム装置１４００から受信したリクエスト情報が新規のオブジェクト（カード）の使用登録操作に該当する場合には（ステップＳ１２のＹＥＳ）、リクエスト情報とともに受信した番号をオブジェクト（カード）登録データ５１８（図１１参照）と照合する（ステップＳ１４）。
【０１５８】
正規のオブジェクト（カード）として登録されているオブジェクト（カード）番号の何れかと受信したオブジェクト（カード）番号とが合致しなければ（ステップＳ１４の不一致）、サーバ処理部２０２は、携帯型ゲーム装置１４００の選手登録画面Ｗ４で入力したオブジェクト（カード）番号が登録できない旨通知表示させるための情報を送信する（ステップＳ１８）。
【０１５９】
正規のオブジェクト（カード）として登録されているオブジェクト（カード）番号の何れかと受信したオブジェクト（カード）番号とが合致すれば（ステップＳ１４の合致）、サーバ処理部２０２は、さらに受信したオブジェクト（カード）番号に対応するオブジェクト（トレーディングカード３）が未使用であるか、すなわち選手登録に使用されていないかを判定する（ステップＳ１６）。
【０１６０】
そして、もし未使用であれば（ステップＳ１６のＴＲＵＥ）、サーバ処理部２０２は当該プレーヤのチーム設定データ６００の選手登録リスト６１０を参照して、同種のオブジェクト（カード）が既に登録されているかを判定する（ステップＳ２０；図２１参照）。
具体的には、オブジェクト（カード）登録データ５１８を参照して、受信したオブジェクト（カード）番号５１８ａに対応づけられている選手ＩＤ５１８ｂ及びシリーズＩＤ５１８ｃの組み合わせと、選手登録リスト６１０（図２６参照）の登録済の選手ＩＤ６１０ａ及びシリーズＩＤ６１０ｂの組み合わせとが合致するものがあれば同種オブジェクト（カード）が登録済と判定し、合致するものが無ければ未登録と判定する。尚、レンタル選手が選手登録リスト６１０に登録されていても、今回新たに登録されるオブジェクト（トレーディングカード３）に対応する選手とレンタル選手とが同一人物であったとしても、そもそもレンタル選手にはレンタル選手固有の選手ＩＤが付与されるので、当該ステップでは同種カードとは認識されないことになる。
【０１６１】
そして、未登録であれば（ステップＳ２０のＮＯ）、サーバ処理部２０２は、当該受信したオブジェクト（カード）番号に対応する選手を新規登録する（ステップＳ２２）。
すなわち、選手登録リスト６１０に、受信したオブジェクト（カード）番号の選手ＩＤ５１８ｂを新たな選手ＩＤ６１０ａとして登録する。そして、これに対応付けて、シリーズＩＤ５１８ｃをコピーしたシリーズＩＤ６１０ｂを格納し、同一選手重複登録数６１０ｃとして初期値「１」を格納する。また、適用攻撃関連パラメータ６１０ｄ及び適用守備関連パラメータ６１０ｅは、それぞれ選手設定データ値５２０（図１２参照）の攻撃関連パラメータ５２２及び守備関連パラメータ５２４の初期設定値そのままをコピーして格納する。また、適用個人戦術傾向パラメータ６１０ｆは、個人戦術傾向パラメータ５３０の初期設定値そのままをコピーして格納する。
【０１６２】
もし、受信したオブジェクト（カード）番号に対応する選手が既に登録されている場合には（ステップＳ２０のＹＥＳ）、サーバ処理部２０２は、選手登録リスト６１０に登録されている選手のうち、同種オブジェクト（カード）と見なされる選手の同一選手重複登録数６１０ｃに今回登録のオブジェクト（カード）の分「１」を加算して更新する（ステップＳ２４）。
【０１６３】
次いで、携帯型ゲーム装置１４００の選手登録画面Ｗ４にて受信したオブジェクト（カード）番号に対応するキャラクタの選手情報表示欄１４に表示させるための表示情報を送信する（ステップＳ２６）。尚、ここでの表示情報には、同一選手重複登録数１４ｄ（図４参照）を表示させるための情報と、同一選手重複登録数が複数の場合には、特典付与状態マーク１４ｅを表示させるための情報を含めるものとする。
【０１６４】
次いで、サーバ処理部２０２は、受信したオブジェクト（カード）番号に対応するキャラクタの更新後の同一選手重複登録数６１０ｃが、特典付与最低基準値（重複登録数条件に相当。例えば、２〜４程度の値。）以上であって（ステップＳ２８のＹＥＳ）、且つ特典付与上限値（例えば、５〜１０程度の値）未満であれば（ステップＳ３０のＹＥＳ）、サーバ処理部２０２は、チーム設定データ６００の選手登録リスト６１０の適用攻撃関連パラメータ６１０ｄ及び適用守備関連パラメータ６１０ｅの中から、先に算出した同一選手重複登録数６１０ｃと同数だけ特典付与対象とするパラメータをランダムに選択する（ステップＳ３２）。
尚、特典付与対象とするパラメータは、ランダム選択に限らず、相対的に他より値が高いパラメータを選択して当該選手の特徴をより増長させるようにしても良い。
【０１６５】
そして、選択した特典付与対象のパラメータの値を加算して更新する（ステップＳ３４）。具体的には、例えば（初期設定値×（同一選手重複登録数×０．０１＋１．０））で加算補正された値を算出するとしても良い。加算量は、パラメータ値の設定範囲に応じて、特典付与によって過剰に特異な能力を有しないように適当に設定すると良い。
【０１６６】
一方、同一選手重複登録数が複数であるが、特典付与上限値に達している場合には（ステップＳ３０のＮＯ）、選手能力のバランスを考慮して特典は付与しない。
【０１６７】
そして、携帯型ゲーム装置１４００からメニュー画面への復帰操作に該当するリクエスト情報を受信した場合には（ステップＳ３６のＹＥＳ）、サーバ処理部２０２は選手登録処理を終了する。
【０１６８】
選手登録処理を終了したならば、図２９のフローチャートに戻って、リクエスト情報から「監督登録」が選択されたと判定される場合（ステップＳ５０のＹＥＳ）、サーバ処理部２０２は監督登録処理を実行する（ステップＳ５２）。
【０１６９】
監督登録処理は、オブジェクト（カード）に対応するキャラクタが監督であるだけで、基本的には選手登録処理と同じである。但し、監督には、選手のように攻撃関連パラメータ及び守備関連パラメータが設定されていないので、選手登録処理のステップＳ３２〜Ｓ３４に相当するステップでは、適用個人戦術パラメータ６０８ｄのうち、設定値が「０」以外の項目のパラメータ値に所定値を加算する処理をする。
【０１７０】
受信したリクエスト情報が「チーム編成」の選択操作に該当する場合には（ステップＳ１００のＹＥＳ）、サーバ処理部２０２はチーム編成処理を実行する（ステップＳ１０２）。
【０１７１】
図３１〜図３２は、チーム編成処理の流れを説明するためのフローチャートである。
サーバ処理部２０２は、先ずスタメン編成タグが選択された状態のチーム編成画面Ｗ６（図５参照）の表示処理を行う（ステップＳ１２２）。即ち、携帯型ゲーム装置１４００でスタメン設定状態表示部２６を表示させる表示情報と、登録選手一覧３６を表示させるための表示情報とを送信する。
【０１７２】
携帯型ゲーム装置１４００では、スタメン設定状態表示部２６の各守備ポジションのうち、当該プレーヤのチーム設定データ６００のスタメンリスト６１２（図２７参照）の選手ＩＤ６１２ｂが登録されているポジションについては、当該選手ＩＤ６１２ｂの示す選手設定データ５２０の選手アイコンデータ５２０ｂ（図１２参照）又はレンタル選手設定データ５３６の選手アイコンデータが表示され、未登録の守備ポジションにはブランクのアイコン３２が表示される。また、登録選手一覧３６には、同一覧の所定表示位置に当該プレーヤのチーム設定データ６００の選手登録リスト６１０に登録されている選手の選手アイコンが表示される。
【０１７３】
携帯型ゲーム装置１４００にて、スタメン設定状態表示部２６の内、プレーヤが選手の設定をしたいと思う守備ポジションの選択操作や、登録選手一覧３６に表示されているアイコンから選択したポジションへ登録したい選手の選択操作、ポジションの設定を解除する「はずす」操作などを入力すると、それらの操作入力に応じたリクエスト情報がサーバシステム１１００へ送信される。
【０１７４】
サーバシステム１１００で受信したリクエスト情報が守備ポジションの選択操作に該当する場合（ステップＳ１２４のＹＥＳ）、サーバ処理部２０２は選択された守備ポジションの識別情報を一時的にサーバ記憶部５０２に格納して、当該守備ポジションを設定対象ポジションとする（ステップＳ１２６）。そして、選手情報表示部３４の表示処理を実行して（ステップＳ１２８）、携帯型ゲーム装置１４００にて、現在設定対象とされている守備ポジションに登録されている選手に係る情報を選手情報表示部３４に表示させるための情報を携帯型ゲーム装置１４００へ送信する。
【０１７５】
そして、受信したリクエスト情報が「はずす」操作に該当する場合（ステップＳ１４０のＹＥＳ）、サーバ処理部２０２はスタメンリスト６１２（図２７参照）において現在設定対象とされている守備ポジションに対応づけて格納されている選手ＩＤ６１２ｂなどのデータをクリアして登録を解除する（ステップＳ１４２）。そして、選手詳細表示部３４の表示を削除してクリアするための処理を実行する（ステップＳ１４４）。
【０１７６】
もし、受信したリクエスト情報が選手の守備ポジションに該当する場合、すなわち設定対象ポジションが選択された状態で登録選手一覧３６の何れかの選手のアイコンを選択する操作が為された場合、又は登録選手一覧３６の何れかの選手のアイコンの設定対象ポジションへのドラック・アンド・ドロップ操作が為された場合（ステップＳ１４６のＹＥＳ）、サーバ処理部２０２は、登録先となる現在の設定対象とされる守備ポジション、又はドロップ先の守備ポジションに既に登録されている選手が有るかを判定する（ステップＳ１５０）。
【０１７７】
もし、既に登録されている選手が無ければ（ステップＳ１５０のＮＯ）、サーバ処理部２０２は、登録選手一覧３６で選択されたアイコン又はドラッグされたアイコンに対応する選手を登録先の守備ポジションに登録し（ステップＳ１５２）、次いで選手情報表示部３４の表示を、選択されたアイコンに対応する選手の表示に変更させる為の情報を送信する（ステップＳ１５４）。反対に登録先の守備ポジションに既に登録されている選手が有る場合（ステップＳ１５０のＹＥＳ）、サーバ処理部２０２は指定重複登録処理を実行する（ステップＳ１６０）。
【０１７８】
図３３は、本実施形態における指定重複処理の流れを説明するためのフローチャートである。同処理では先ず、サーバ処理部２０２は、登録先とされる守備ポジションに登録されている選手が、登録選手一覧３６から選択されたアイコン又はドラック・アンド・ドロップ操作されたアイコンの選手と同じであるかを判定する（ステップＳ１６２）。この場合、当該選手に対応するオブジェクト（トレーディングカード３）のシーズンの違いは問わない。
【０１７９】
もし、否定判定された場合、即ち既に選手が登録されている守備ポジションに違う種類の選手（異なる人物の意）を登録しようとした場合には（ステップＳ１６２のＮＯ）、サーバ処理部２０２は携帯型ゲーム装置１４００にて設定対象の守備ポジションの選手登録を「はずす」ように促す表示をさせるための処理を実行する（ステップＳ１６４）。
もし、肯定判定された場合、即ち既に登録されている選手と同じ選手を重複して登録しようとした場合には（ステップＳ１６２のＹＥＳ）、サーバ処理部２０２は設定対象ポジションに登録されている選手、又はドロップ先の守備ポジションに登録されている選手の同一選手重複登録数６１０ｃを「１」加算して更新する（ステップＳ１６６）。
【０１８０】
次いで、サーバ処理部２０２は、その更新した後の同一選手重複登録数６１０ｃが所定の特典付与上限に達していなければ（ステップＳ１６８のＹＥＳ）、当該選手の適用攻撃関連パラメータ６１０ｄ及び適用守備関連パラメータ６１０ｅの中から補正後の同一選手重複登録数６１０ｃの数だけパラメータを特典付与対象としてランダムに選択する（ステップＳ１７０）。そして、特典付与対象のパラメータの値に所定値を加算して更新し（ステップＳ１７２）、重複して登録しようとした選手の情報を選手登録リスト６１０から抹消する（ステップＳ１７４）。次いで、サーバ処理部２０２は、選手情報表示部３４の表示を更新させるための情報を送信し（ステップＳ１７６）、指定重複登録処理を終了する。
【０１８１】
尚、この場合の重複登録は、同じ選手を想起させるが意匠違いのオブジェクト（カード）の登録を纏めることになるので、ステップＳ１７２で特典として加算される値は、選手登録処理における重複登録の特典付与（図３０のステップＳ３２）の時より高くするとゲームの興趣を高める上で好適である。更には、選手登録リスト６１０にて、指定重複登録処理で重複登録されたオブジェクト（カード）のシリーズＩＤの履歴を格納する構成として、重複使用登録されたオブジェクト（カード）のシリーズが所定数連続する（例えば、第１弾から第３弾までのような３つ連続するなど）など特定の条件を満たす場合に、更に異なる加算値を設定する構成とするならば、より一層ゲームの興趣を高める上で好適である。
【０１８２】
もし、更新した後の同一選手重複登録数６１０ｃが所定の特典付与上限に達しているならば（ステップＳ１６８のＮＯ）、ステップＳ１７０〜Ｓ１７６はスキップして、指定重複登録処理を終了する。
【０１８３】
図３２のフローチャートに戻って、サーバシステム１１００で受信したリクエスト情報が交代要員編成タグ２２の選択操作に該当する場合には（ステップＳ１９０のＹＥＳ）、サーバ処理部２０２は、交代要員の編成処理を実行する（ステップＳ１９２）。同処理では、例えば交代要員の登録枠と、登録選手一覧３６とを表示させ、登録選手一覧３６に表示される選手アイコンを登録枠へドラック・アンド・ドロップ操作することで交代要員を設定する。
【０１８４】
また、サーバシステム１１００で受信したリクエスト情報が控え投手編成タグ２４の選択操作に該当する場合には（ステップＳ１９４のＹＥＳ）、サーバ処理部２０２は控え投手の編成処理を実行する（ステップＳ１９６）。同処理では、例えば控え投手の登録枠と、登録選手一覧３６とを表示させ、登録選手一覧３６に表示される選手アイコンを登録枠へドラック・アンド・ドロップ操作することで控え投手を登録する。
【０１８５】
次に、サーバ処理部２０２は、選手登録リスト６１０に登録されている全選手が、スタメン、控え投手、交代要員の何れかに設定されていて（ステップＳ２００のＹＥＳ）、且つ、それでいて選手が登録されていない守備ポジションが有るかを判定する（ステップＳ２０２）。すなわち、選手登録された分ではゲームプレイに不足するかを判定する。
【０１８６】
該当する守備ポジションがあるならば（ステップＳ２０２のＹＥＳ）、サーバ処理部２０２はレンタル選手設定データ５３６から何れかの選手をランダムに選択して、該当する守備ポジションへ自動登録処理するとともに、選手登録リスト６１０にも選択されたレンタル選手を自動登録する（ステップＳ２０４）。そして、携帯型ゲーム装置１４００でその旨通知する為の処理を実行する（ステップＳ２０６）。
該当する守備ポジションがなければ（ステップＳ２０２のＮＯ）、ステップＳ２０４とＳ２０６はスキップされる。
【０１８７】
これまでの処理で、チーム編成ができたことになる。プレーヤはチーム編成を終了するためにメニュー画面Ｗ２への復帰操作をすることとなる。そして、サーバシステム１１００で受信したリクエスト情報がメニュー画面Ｗ２への復帰操作に該当する場合には（ステップＳ２０８のＹＥＳ）、サーバ処理部２０２はチームパラメータ変更処理を実行する（ステップＳ２１０）。
【０１８８】
図３４は、本実施形態におけるチームパラメータ変更処理の流れを説明するためのフローチャートである。同処理は、重複登録された選手の組み合わせに応じてチームパラメータを自動的に変更して特典を付与するための処理である。
【０１８９】
同処理では先ず、サーバ処理部２０２は、選手登録リスト６１０から同一選手重複登録数６１０ｃが複数である選手を抽出する（ステップＳ２５０）。
そして、抽出された選手が所定のポジション条件を満たすか否かを判定する（ステップＳ２５２）。ここで言う「ポジション条件」とは、重複登録された選手の守備ポジションの組み合わせである。本実施形態では、「投手and捕手（バッテリー）」とするが、それ
以外にも「ライトandセンターandレフト」など適宜設定できる。
【０１９０】
そして、抽出された選手がポジション条件を満たす場合（ステップＳ２５２のＹＥＳ）、サーバ処理部２０２は、ポジション条件を満たす選手の適用攻撃関連パラメータ６１０ｄ及び適用守備関連パラメータ６１０ｅのうち所定の項目のパラメータ値を、パラメータが向上するように所定量変更する（ステップＳ２５４）。
【０１９１】
更に、サーバ処理部２０２は、適用個人戦術傾向パラメータ６１０ｆのうち所定の項目のパラメータ値を所定量変更する（ステップＳ２５６）。
適用個人戦術傾向パラメータ６１０ｆは、チームの戦術決定に影響を与えるファクタであるから、適用個人戦術傾向パラメータ６１０ｆの変更はとりもなおさずチームパラメータの変更となる。尚、ゲーム内容によっては、例えばチーム編成するＲＰＧ（role-playing game）におけるチーム移動速度などのようにチーム全体に適用されるパラメータ値が存在する場合には、ステップＳ２５６では、そうしたパラメータ値を変更すれば良い。
【０１９２】
抽出された選手がポジション条件を満たさなければ（ステップＳ２５２のＮＯ）、ステップＳ２５４からＳ２５６はスキップされる。
【０１９３】
次に、サーバ処理部２０２は、抽出された選手が所定の実チーム条件を満たすかを判定する（ステップＳ２５８）。ここで言う「実チーム条件」とは、抽出された選手が実際の野球リーグにおいて所属するチームの組み合わせを示す条件である。本実施形態では「同一チーム」とするが、サッカーやＲＰＧなどその他のゲーム内容では「敵対する国のチーム」「同じ国のリーグに属するチーム」などゲーム世界の背景設定に応じて適宜設定することができる。
【０１９４】
そして、もし所定の実チーム条件を満たした場合には（ステップＳ２５８のＹＥＳ）、サーバ処理部２０２は抽出された選手の適用個人戦術傾向パラメータ６１０ｆのうち所定の項目のパラメータ値を所定量変更する（ステップＳ２６０）。
【０１９５】
次いでサーバ処理部２０２は、当該チームの監督の同一監督重複登録数６０８ｃが複数である場合（ステップＳ２６２のＹＥＳ）、当該監督の適用個人戦術傾向パラメータ６０８ｄのうち所定の項目のパラメータ値を所定量変更して（ステップＳ２６４）、チームパラメータ変更処理を終了する。もし、同一監督重複登録数６０８ｃが単数であれば（ステップＳ２６２のＮＯ）、ステップ２６２をスキップしてチームパラメータ変更処理を終了する。
【０１９６】
チームパラメータ変更処理を終了したならば、サーバ処理部２０２はチーム編成処理を終了し、図２９のフローチャートに戻る。
【０１９７】
メニュー画面Ｗ２において、受信したリクエスト情報が「リーグ作成」に該当する場合（ステップＳ３００のＹＥＳ）、サーバ処理部２０２はリーグ作成処理を実行する（ステップＳ３０２）。
【０１９８】
図３５は、リーグ作成処理の流れを説明するためのフローチャートである。サーバ処理部２０２は、先ずリーグ設定画面表示処理を実行し、リーグ設定画面Ｗ１０（図６参照）を表示させるための表示情報を携帯型ゲーム装置１４００へ送信する（ステップＳ３０４）。そして、新たなリーグ設定データ５５０を準備する（ステップＳ３０６；図１５参照））。この時、レギュレーション設定データ５５０ｃの各項目の設定内容は所定のデフォルトとされる。
【０１９９】
携帯型ゲーム装置１４００でリーグ設定画面Ｗ１０における操作入力がなされると、リーグＩＤ設定欄６０、参加パスワード設定欄６２、レギュレーション設定部６６への各種操作入力に応じたリクエスト情報がサーバシステム１１００へ送信される。
【０２００】
サーバ処理部２０２は、リーグＩＤ設定欄６０、参加パスワード設定欄６２への操作入力に基づくリクエスト情報を受信して、先に生成したリーグ設定データ５５０のリーグＩＤ５５０ａ、参加パスワード５５０ｂを設定する（ステップＳ３０８）。
また、レギュレーション設定部６６への操作入力に基づくリクエスト情報を受信して、先に生成したリーグ設定データ５５０のレギュレーション設定データ５５０ｃの各項目の設定内容を変更する（ステップＳ３１０）。
【０２０１】
次に、サーバ処理部２０２は、受信したリクエスト情報が設定終了操作に該当する場合（ステップＳ３１２のＹＥＳ）、今回新たに生成したリーグのリーグＩＤと参加パスワードとを対応づけてリーグ登録リスト５５１に追加登録する（ステップＳ３１４）。そして、当該リーグに対応する新たなリーグ参加チームリスト５５２を生成する（ステップＳ３１６；図１６参照）。
【０２０２】
もし、受信したリクエスト情報が現在の設定内容を全て破棄する「全クリア」に該当する場合には（ステップＳ３１８のＹＥＳ）、サーバ処理部２０２は今回新たに作成したリーグ設定データ５５０を削除する（ステップＳ３２０）。
【０２０３】
そして、受信したリクエスト情報がメニュー画面への復帰操作に該当する場合（ステップＳ３２２のＹＥＳ）、サーバ処理部２０２はリーグ作成処理を終了する。
【０２０４】
図２９のフローチャートに戻って、リクエスト情報から「リーグ参加」が選択されと判定される場合（ステップＳ３５０のＹＥＳ）、サーバ処理部２０２はリーグ参加処理を実行する（ステップＳ３５２）。
【０２０５】
リーグ参加処理は、プレーヤの操作入力に応じて、既に作成されているリーグへの参加登録のための処理である。
具体的には、サーバ処理部２０２は、携帯型ゲーム装置１４００へ参加リーグ設定画面Ｗ１２表示させるための表示情報を送信する（図７参照）。携帯型ゲーム装置１４００では、ソフトウェアキーボード７４によりリーグＩＤ入力欄７０と参加パスワード入力欄７２への入力が可能になり、入力に応じたリクエスト情報がサーバシステム１１００へ送信される。そして、受信したリクエスト情報がリーグＩＤと参加パスワードに該当する場合には、サーバ処理部２０２はそれらをリーグ設定データ５５０と照合する。もし、合致する登録があれば、サーバ処理部２０２は、合致したリーグＩＤ５５０ａを当該プレーヤのチーム設定データ６００の参加リーグＩＤ６１８に設定し、当該リーグのリーグ参加チームリスト５５２に、当該プレーヤのチーム情報を登録・更新して参加登録する。受信したリクエスト情報がメニュー画面への復帰操作に該当する場合には、サーバ処理部２０２はリーグ参加処理を終了する。
【０２０６】
受信したリクエスト情報が「試合」の選択操作に該当する場合には（ステップＳ３７０のＹＥＳ）、サーバ処理部２０２は試合シミュレーション処理を実行する（ステップＳ３７２）。
【０２０７】
図３６〜図３７は、試合シミュレーション処理の流れを説明するためのフローチャートである。同処理において、サーバ処理部２０２は先ず、プレイデータ６５０をサーバ記憶部５０２に新たに生成する。そして、チーム設定データ６００の参加リーグＩＤ６１８を参照し、現在プレーヤのチームが参加しているリーグ参加チームリスト５５２からプレーヤのチームと対戦するチームをランダムに選択し、先攻後攻を自動設定する（ステップＳ３８０）。対戦する２チームのチームＩＤと先攻後攻の情報は、プレイデータ６５０の対戦チーム情報６５２に格納される。
【０２０８】
次いでサーバ処理部２０２は、試合を開始するとともに、試合画像の生成を開始する（ステップＳ３８２）。今現在のイニングと裏／表の識別などの情報は、プレイデータ６５０にイニング情報６５４として記憶される。
【０２０９】
ゲームが開始されたならば、サーバ処理部２０２は、携帯型ゲーム装置１４００へ向けて試合画像とゲーム進行情報（例えば、カウント、進塁情報、得点情報など）とを表示させる為の表示情報の送信を開始する（ステップＳ３８４）。これに伴い、携帯型ゲーム装置１４００では、試合シミュレーション画面Ｗ１４（図８参照）が表示され、試合画面表示部８２に試合の様子が映しだされ、スコアボード８０やカウント表示部８４、進塁状況表示部８６の表示が開始される。
【０２１０】
また、試合が開始されたならば、サーバ処理部２０２は、先ず攻撃チームの打順に従って打者を選択し（ステップＳ３８６）、次いで打者交代処理を実行する（ステップＳ３８８）。打者交代処理は、攻撃に伴うＡＩ処理の一つであり、代打を出すのが適当であるかを判定し、適当な場合に控え要員に登録されている選手から適当な選手を代打として設定する処理を実行する。
【０２１１】
サーバ処理部２０２は、次いで攻撃戦術決定処理を実行する（ステップＳ３９０）。
【０２１２】
図３８は、攻撃戦術決定処理の流れを説明するためのフローチャートである。
同処理において、サーバ処理部２０２は先ず、選手登録リスト６１０を参照し、攻撃チームのうち現在出場中の選手（試合開始当初は、スタメンの設定と同じ。途中交代があれば、交代後のメンバーの意）の適用個人戦術傾向パラメータ６１０ｆ内の攻撃戦術傾向パラメータの項目毎にパラメータ値の合計を算出し、それを攻撃チームの基礎攻撃戦術傾向パラメータ６６０とする（ステップＳ４００）。つまり、所定のメンバー条件を満たす選手の適用個人戦術傾向パラメータ６１０ｆに基づいてチームの基礎的な攻撃戦術の選択傾向を決定し、チームの攻撃能力を変更したことになる。現在出場中の選手としたが、交代要員選手及び控え投手を含めた今回の試合への登録選手全員を所定のメンバー条件として基礎攻撃戦術傾向パラメータ６６０の値を決定することとしてもよい。
【０２１３】
次いで、サーバ処理部２０２は、基礎攻撃戦術傾向パラメータ６６０に、今現在の打者となる選手（攻撃に強い影響を与える主要キャラクタ）の適用個人戦術傾向パラメータ６１０ｆ内の攻撃戦術傾向パラメータをもう一度項目毎に加算して、中間攻撃戦術傾向パラメータ６６４を算出する（ステップＳ４０２）。更に、この中間攻撃戦術傾向パラメータ６６４に、本実施形態における主要キャラクタの一つである監督の適用個人戦術傾向パラメータ６０８ｄ内の攻撃戦術傾向パラメータを項目毎に加算して、今回の打席における最終攻撃戦術傾向パラメータ６６８を決定する（ステップＳ４０４）。
【０２１４】
次に、サーバ処理部２０２は「犠牲バント」の適当条件を満たすかを判定する（ステップＳ４０６）。犠牲バント適当条件テーブル５６０を参照して（図１９参照）、出塁状況５６０ａ毎に定められた犠牲バント適当条件５６０ｂを満たせば（ステップＳ４０６のＹＥＳ）、サーバ処理部２０２は更に犠牲バント選択確率データ５６１（図２０参照）を参照して、最終攻撃戦術傾向パラメータ６６８に応じた選択確率で、犠牲バントの採否を決定する（ステップＳ４０８）。そして、「犠牲バント」が採用されたならば（ステップＳ４１０のＹＥＳ）、今打席の攻撃戦術を「犠牲バント」に設定し（ステップＳ４１２）、攻撃戦術決定処理を終了する。
【０２１５】
犠牲バント適当条件を満たさないと判定された場合（ステップＳ４０６のＮＯ）、又は犠牲バントが採用されなかった場合には（ステップＳ４１０のＮＯ）、サーバ処理部２０２は次ぎにエンドラン適当条件を満たすかを判定する（ステップＳ４２０）。
【０２１６】
エンドラン適当条件テーブル５６２を参照して、出塁状況等に応じて定められたエンドラン適当条件を満たせば（ステップＳ４２０のＹＥＳ）、サーバ処理部２０２は更にエンドラン選択確率テーブル５６３を参照して、最終攻撃戦術傾向パラメータ６６８に応じた選択確率でエンドランの採否を決定する（ステップＳ４２２）。そして、「エンドラン」が採用されたならば（ステップＳ４２４のＹＥＳ）、今打席の攻撃戦術を「エンドラン」に設定し（ステップＳ４２６）、攻撃戦術決定処理を終了する。
【０２１７】
エンドラン適当条件を満たさないと判定された場合（ステップＳ４２０のＮＯ）、又はエンドランが採用されなかった場合には（ステップＳ４２４のＮＯ）、サーバ処理部２０２は次ぎにセーフティバント適当条件を満たすかを判定する（ステップＳ４３０）。
【０２１８】
セーフティバント適当条件テーブル５６４を参照して、打者の打撃能力と走力に基づくセーフティバント適当条件を満たせば（ステップＳ４３０のＹＥＳ）、サーバ処理部２０２は更にセーフティバント選択確率テーブル５６５を参照して、最終攻撃戦術傾向パラメータ６６８に応じた選択確率で、セーフティバントの採否を決定する（ステップＳ４３２）。そして、「セーフティバント」が採用されたならば（ステップＳ４３４のＹＥＳ）、今打席の攻撃戦術を「セーフティバント」に設定し（ステップＳ４３６）、攻撃戦術決定処理を終了する。
【０２１９】
犠牲バント、エンドラン、セーフティバントの何れの適当条件も満たさない場合には、サーバ処理部２０２は通常の打撃による攻撃戦術を選択する（ステップＳ４３８）。
具体的には、通常攻撃戦術選択確率テーブル５６６（図２１参照）で定義されている「早打ち・長打狙い」「遅打ち・長打狙い」「早打ち・単打狙い」「遅打ち・単打狙い」それぞれの選択確率に従って何れかの戦術に決定し、攻撃戦術決定処理を終了する。
【０２２０】
図３６のフローチャートに戻って、サーバ処理部２０２は次に走者交代処理を実行する（ステップＳ４５０）。
走者交代処理は、代走を出した方が良いかを判定するための処理である。例えば、サーバ処理部２０２は先ず、代走適当条件を満たすかを判定する。代走適当条件とは、代走を送るのが適当と考えられる試合状況である。例えば、走者が居て、且つ攻撃チームが負けている又は僅差で勝っている場合などであり、公知の野球ゲームにおける走者交代の発動条件と同様に実現できる。
そして、代走適当条件を満たす場合、プレイデータ６５０の選手パラメータデータ６５６を参照して、現在の走者の中に、走力が所定の基準値を下回る走者の有無を判定する。もし、該当する走者が有る場合には、代走の採否決定処理を実行する。当該処理において代走の採用が選択される確率は、イニングが７回未満では低く、７回以降回を重ねるごとに採用確率が高まるように設定されている。そして、代走が採用された場合には、サーバ処理部２０２は交代要員に登録されている選手を、基準値を下回ると判定された走者の代走に設定する。
【０２２１】
次に、サーバ処理部２０２は、守備交代処理を実行する（ステップＳ４５２）。
守備交代処理は、守備力の強化のために選手交代をするかを判定する処理である。例えば、サーバ処理部２０２は、先ず守備力強化状況条件の一つである守備交代適当条件を満たすかを判定する。守備交代適当条件は、守備交代すべき状況を定義する。例えば、イニングが７回以降で、且つ守備チームが３点以内の点差で勝っていて、且つ打順が１〜３番で有る場合、など守備交代が適当と思われる条件と同様に設定できる。
【０２２２】
そして、守備交代条件を満たすと判定した場合、サーバ処理部２０２は現在守備についている全野手の選手設定データ５２０の守備適性データ５２６を参照し、現在の守備ポジションに対する守備適性値が所定の基準値を下回る野手の有無を判定する。
もし、基準値を下回る野手がいれば、サーバ処理部２０２は守備交代の採否決定処理を実行する。当該処理において守備交代の採用が選択される確率は、イニングが７回未満では低く、７回以降回を重ねるごとに採用確率が高まるように設定されている。そして、守備交代が採用された場合には、サーバ処理部２０２は交代要員に登録されている選手の一人を、先に基準値を下回ると判定された野手と交代させる。
【０２２３】
次いで、サーバ処理部２０２は、守備戦術決定処理を実行する（ステップＳ４５４）。
【０２２４】
図３９は、守備戦術決定処理の流れを説明するためのフローチャートである。
同処理において、サーバ処理部２０２は先ず、守備チームの選手のうち現在試合に出場している選手、つまり控えではない選手の適用個人戦術傾向パラメータ６１０ｆ内の守備戦術傾向パラメータの項目毎にパラメータ値の合計を算出し、それを攻撃チームの基礎守備戦術傾向パラメータ６６２とする（ステップＳ４６２；図２８参照）。つまり、所定のメンバー条件を満たす選手の適用個人戦術傾向パラメータ６１０ｆに基づいてチームの基礎的な守備戦術の選択傾向を決定し、チームの防御能力を変更したことになる。
【０２２５】
次いで、サーバ処理部２０２は、基礎守備戦術傾向パラメータ６６２に、本実施形態における主要キャラクタの一つである現在登板中の投手の適用個人戦術傾向パラメータ６１０ｆ内の守備戦術傾向パラメータをもう一度加算して、中間守備戦術傾向パラメータ６６６を算出する（ステップＳ４６４）。更に、この中間守備戦術傾向パラメータ６６６に本実施形態における主要キャラクタの一つである監督の適用個人戦術傾向パラメータ６０８ｄ内の守備戦術傾向パラメータを項目毎に加算して、今回の打席における最終守備戦術傾向パラメータ６７０を決定する（ステップＳ４６６）。
【０２２６】
次に、サーバ処理部２０２は敬遠選択条件を満たすかを判定する（ステップＳ４６８）。敬遠選択条件テーブル５７０を参照して（図２２参照）、最終守備戦術傾向パラメータ６７０のうち「敬遠」の値５７０ａに対して、打者の打撃能力が所定の適当条件を満たせば（ステップＳ４６８のＹＥＳ）、今打席における守備戦術を「敬遠」に決定し（ステップＳ４７０）、守備戦術決定処理を終了する。
【０２２７】
もし、敬遠選択条件を満たさなければ（ステップＳ４６８のＮＯ）、サーバ処理部２０２は次に最終守備戦術傾向パラメータ６７０に基づく奇襲警戒適当条件を満たすかを判定する（ステップＳ４７２）。
【０２２８】
そして、奇襲警戒適当条件テーブル５７２を参照して（図２３参照）、出塁状況５７２ａと打者の「ミート力」や「走力」といった攻撃関連パラメータとに基づく適当条件５７２ｂを満たす場合（ステップＳ４７２のＹＥＳ）、サーバ処理部２０２は更に奇襲警戒選択確率テーブル５７４を参照して（図２４参照）、最終守備戦術傾向パラメータ６７０の「奇襲警戒」の値と得点差とに基づいて対応づけられた選択確率で、「奇襲警戒」の採否を判定する（ステップＳ４７４）。つまり、状況的には奇襲警戒しても良いが、実際に奇襲警戒策をとるか否かを決定する。
【０２２９】
そして、奇襲警戒が採用された場合には（ステップＳ４７６のＹＥＳ）、サーバ処理部２０２は今回の打者に対する守備戦術を「奇襲警戒」に決定し（ステップＳ４７８）、守備戦術決定処理を終了する。
【０２３０】
一方、そもそも奇襲警戒適当条件を満たさない場合（ステップＳ４７２のＮＯ）、及び採否判定処理で奇襲警戒が採用されなかった場合（ステップＳ４７６のＮＯ）、サーバ処理部２０２は、通常守備戦術選択確率テーブル５７６を参照する（図２３参照）。そして、最終守備戦術傾向パラメータ６７０の「打撃警戒」の値と、「勝負カウント」の値とに基づいて、「早め勝負・長打警戒」「遅め勝負・長打警戒」「早め勝負・短打警戒」「遅め勝負・短打警戒」の何れかの戦術を選択・決定し（ステップＳ４８０）、守備戦術決定処理を終了する。
【０２３１】
図３６の試合シミュレーション処理のフローチャートに戻って、サーバ処理部２０２は次に、打撃パターンデータ５５５を参照し（図１８参照）、先に選択された攻撃戦術に対応する打撃パターンの設定に従って打者を制御する（ステップＳ５００）。より具体的には、現在の投球順５５５ａに対応するジャストミート、標準ミート、打ち損ね、見送りの各確率に従って打撃内容を決定し、決定した打撃内容を実現する動作をさせる。
【０２３２】
次いで、サーバ処理部２０２は、先に選択された攻撃戦術に従って走塁制御をする（ステップＳ５０２）。例えば攻撃戦術として「エンドラン」が選択された場合には、投球と同時に走者を走らせる。
【０２３３】
次いで、サーバ処理部２０２は、守備シフトデータ５５６を参照して、先に選択された守備戦術に対応する守備シフトパターンに従って、野手の守備隊形を制御する（ステップＳ５０４）。
【０２３４】
次いで、投球パターンデータ５５４を参照して（図１７参照）、先に選択された守備戦術に対応する投球パターンの設定に従って投手の投球を制御する（ステップＳ５０６）。具体的には、その時の投球順５５４ｂに対応する勝負球の選択、投球ゾーンの選択、球速の選択、球威の選択の各確率に基づいて、どこにどんな球を投球するか、その投球内容を決定し、それに応じた投球動作制御をする。
【０２３５】
この段階で、攻守両方の行動が決まった事になるので、図３７のフローチャートに移って、サーバ処理部２０２は次に攻守の結果を算出し（ステップＳ５０８）、その結果に応じてカウントや進塁状況、得点などのゲーム進行情報を更新する（ステップＳ５１０）。
【０２３６】
すなわち、試合を自動制御する公知の野球ゲームと同様にして、ストライク及びボールのカウント、飛球の種類とその飛球を捕球できた／できない、敬遠、牽制球のアウト／セーフ、盗塁の成功／失敗、などが決定される。
飛球の種類の判定については、例えば、打撃パターンデータ５５６に基づいて決定された打撃の結果（ジャストミート、標準ミート、打ち損ねの何れか）と、投球パターンデータ５５４に基づいて決定された投球内容との相関関係に、飛球の種類と位置を対応づけたテーブルデータをサーバ記憶部５０２に予め記憶させておいて、これを参照して決定しても良い。勿論、その他の方法でも良い。
【０２３７】
次に、サーバ処理部２０２は、攻守結果によりチェンジになったかを判定する。チェンジにならず（ステップＳ５１２のＮＯ）、打者が進塁していれば（ステップＳ５１４のＹＥＳ）、ステップＳ３９０に戻って、現在の打者に対するシミュレーションが繰り返される。
一方、チェンジにならないが、打者が進塁していなければ（ステップＳ５１４のＮＯ）、ステップＳ３８６に戻って、新たな打者の選択からシミュレーションが繰り返される。
【０２３８】
もし、チェンジになったならば（ステップＳ５１２のＹＥＳ）、サーバ処理部２０２は試合終了条件を満たすかを判定する。試合終了条件を満たさなければ（ステップＳ５１６のＮＯ）、イニング数とその裏表の識別を更新し（ステップＳ５１８）、攻守のチームを反転する（ステップＳ５２０）。そして、サーバ処理部２０２は、攻守反転により守備側になったチームに投手がいるかを判定する。投手がいなければ（ステップＳ５２２のＮＯ）、控え投手リスト６１６に登録されている選手の中から新しい投手を選択して、打順９番の選手と交代し（ステップＳ５２４）、ステップＳ３８６に戻る。
【０２３９】
一方、試合終了条件を満たしていれば（ステップＳ５１６のＹＥＳ）、サーバ処理部２０２は試合画面とゲーム進行情報を携帯型ゲーム装置１４００で表示させる為の表示情報の生成と送信を終了し（ステップＳ５３０）、今回の試合で対戦した両チームの成績を更新して（ステップＳ５３２）、試合シミュレーション処理を終了する。
【０２４０】
図２９のフローチャートに戻って、受信したリクエスト情報が「チャット」機能の選択に該当する場合には（ステップＳ５５０のＹＥＳ）、サーバ処理部２０２はチャット処理を実行して、携帯型ゲーム装置１４００にチャット機能を提供する（ステップＳ５５２）。
【０２４１】
以上、本実施形態によれば、同種のオブジェクト（トレーディングカード３）を手に入れても、重複して登録可能になり、更に重複数に応じて特典が付与される。よって、同種のオブジェクト（トレーディングカード３）を複数枚所有することとなってもそれらのオブジェクト（カード）は無駄にならず、むしろゲームの興趣を高めるように使える。
【０２４２】
〔変形例〕
以上、本発明を適用した第１実施形態について説明したが、本発明を適用可能な形態はこれに限られるものではなく、発明の主旨を逸脱しない限りに於いて、適宜ゲーム内容や、システムや機能の構成要素を追加・省略・変更を行うことができる。
【０２４３】
例えば、上記実施形態では、野球ゲームを例に挙げたが、同種のオブジェクトの複数登録が可能なゲームであれば、サッカーやホッケー、ラグビー、アメリカンフットボール、バレーボールなどその他のスポーツに限られず、チーム対戦のバトル（戦闘）ゲームにも同様に適用できる。またそれに伴い、対戦するチームを決定する母集団は、上記実施形態のようなリーグに限らず、トーナメントなどその他に設定することができるのは勿論である。
【０２４４】
また、上記実施形態では、プレーヤチームの監督について使用登録されたオブジェクトＩＤの使用登録の重複数に基づいて、プレーヤチーム全体のパラメータを変更するようにしたが、監督に限らず、コーチやオーナー等、プレーヤチームに関連するキャラクタについて使用登録されたオブジェクトＩＤの使用登録の重複数に基づいて、プレーヤチーム全体のパラメータを変更するようにしても良い。
【０２４５】
また、上記実施形態では、プレーヤチームの所属選手のパラメータやプレーヤチーム全体のパラメータを主に「能力」として説明したが能力に限られず「体力」であっても良い。
【０２４６】
また、上記実施形態では、ゲームシステムをサーバシステム１１００とプレーヤ端末を含み、ゲーム管理の処理をサーバシステム１１００で実行する構成としたが、サーバシステム１１００とプレーヤ端末とを１台の据え置き型家庭用ゲーム装置或いは業務用ゲーム装置で実現したゲームシステムとしても良い。また、ゲームセンタなどの店舗で本発明のゲームシステムを使用する場合には、プレーヤ端末として業務用ゲーム装置を用いるとしても良い。
【０２４７】
また、上記実施形態では試合する２チーム両方の行動を自動制御する例を挙げたが、守備側チーム及び攻撃側チームの一方のチームをコンピュータ制御させ、他方のチームをプレーヤ自身が制御する構成としても良い。
【０２４８】
また、上記実施形態では、ゲーム内に登場するキャラクタを対応づけたオブジェクトは、それぞれに付与された固有の識別情報がプレーヤにより読取り可能、又はバーコードリーダやＩＣタグリーダなどの装置で読取り可能になっていれば、トレーディングカードに限らずボトルキャップやフィギュア等の玩具や文具などその他の物品でも良く、また、ウェブサイトでの仮想店舗等で購入する仮想のトレーディングカードや玩具等でも良い。この場合にはデータを購入することとなり、カードや玩具は実在しない。
【０２４９】
また、上記実施形態では、オブジェクト（トレーディングカード３）には、それぞれ固有のカードＩＤが設定される構成としたが、選手とシリーズの組み合わせ、つまりオブジェクト（カード）のモデルに応じて固有のカードＩＤが付与された構成としても良い。
【符号の説明】
【０２５０】
２…プレーヤ
３…オブジェクト（トレーディングカード）
８…メニュー選択アイコン表示部
１０…カード番号入力欄
１４…選手情報表示部
１６…登録選手一覧
１８…操作案内表示
２０…スタメン編成タグ
２２…交代要員編成タグ
２４…投手編成タグ
２６…スタメン設定状態表示部
３０…選手アイコン
３４…選手情報表示部
３５…打順指定欄
５２…交代目的選択欄
６０…リーグＩＤ設定欄
６２…参加パスワード設定欄
６６…レギュレーション設定部
７０…リーグＩＤ入力欄
７２…パスワード入力欄
７６…リーグ一覧表示
８２…試合画面表示部
２０２…サーバ処理部
２２０…ゲーム管理部
２２２…カード登録処理部
２２４…チーム編成処理部
２２６…チーム傾向決定部
２２８…戦術決定処理部
２３０…ゲーム進行制御部
２３２…チャット制御部
２３４…リーグ作成処理部
２３６…リーグ参加設定処理部
５００…記憶部
５０６…ゲーム画面表示制御プログラム
５０２…サーバ記憶部
５１２…サーバシステムプログラム
５１４…ゲーム管理プログラム
５１６…ゲーム関連データ
５１８…カード登録データ
５２０…選手設定データ
５２２…攻撃関連パラメータ
５２４…守備関連パラメータ
５２６…守備適性データ
５３０…個人戦術傾向パラメータ
５３２…攻撃戦術傾向パラメータ
５３４…守備戦術傾向パラメータ
５４０…監督設定データ
５５０…リーグ設定データ
５５１…リーグ登録リスト
５５２…リーグ参加チームリスト
５６０…犠牲バント適当条件テーブル
５６１…犠牲バント選択確率テーブル
５６２…エンドラン適当条件テーブル
５６３…エンドラン選択確率テーブル
５６４…セーフティバント適当条件テーブル
５６５…セーフティバント選択確率テーブル
５６６…通常攻撃戦術選択確率テーブル
５７０…敬遠選択条件テーブル
５７２…奇襲警戒適当条件テーブル
５７４…奇襲警戒選択確率テーブル
５７６…通常守備戦術選択確率テーブル
６００…チーム設定データ
６１２…スタメンリスト
６１４…交代要員リスト
６５０…プレイデータ
６６０…基礎攻撃傾向パラメータ
６６２…基礎守備傾向パラメータ
６６４…中間攻撃傾向パラメータ
６６６…中間守備傾向パラメータ
６６８…最終攻撃傾向パラメータ
６７０…最終守備傾向パラメータ
１１００…サーバシステム
１４００…携帯型ゲーム装置
１４５０…制御ユニット
Ｗ２…メニュー画面
Ｗ４…選手登録画面
Ｗ６…チーム編成画面
Ｗ１２…参加リーグ設定画面
Ｗ１４…試合シミュレーション画面
【特許請求の範囲】
【請求項１】
チーム対戦のゲームを実行するための各プレーヤチームの所属選手を管理するコンピュータシステムであって、
複数の選手それぞれに対応づけて、当該選手に関するオブジェクトに付与されたオブジェクト固有のＩＤ（以下「オブジェクトＩＤ」という。）を記憶する記憶手段と、
プレーヤ端末からの操作入力に従って前記オブジェクトＩＤの使用登録要求を受け付ける受付手段と、
前記受付手段により受け付けられたオブジェクトＩＤが、既に登録済みであった場合には使用登録を不許可とし、未登録であった場合には使用登録を許可として、各オブジェクトＩＤの使用登録の有無を管理する登録管理手段と、
前記登録管理手段により使用登録されたオブジェクトＩＤに対応する選手を、プレーヤチームの所属選手とすることで、各プレーヤチームの所属選手を管理する所属選手管理手段と、
各プレーヤチームについて、当該プレーヤチームの各所属選手の使用登録の重複数に基づき、前記ゲームでの当該プレーヤチームにおける当該所属選手の能力パラメータを変更するパラメータ変更処理を実行するパラメータ変更手段と、
を備えたコンピュータシステム。
【請求項２】
前記所属選手管理手段は、前記プレーヤチームの所属選手として、能力パラメータの値が前記使用登録による所属選手より劣るように設定されたレンタル選手を管理し、当該レンタル選手と前記使用登録されたオブジェクトＩＤに対応する選手とが同一選手であった場合に、当該レンタル選手を所属選手から除外するレンタル選手管理手段を有する、
請求項１に記載のコンピュータシステム。
【請求項３】
前記ゲームの実行ルールとして同一選手の重複登録の可否を設定する重複登録可否設定手段を更に備えた、
請求項１又は２に記載のコンピュータシステム。
【請求項４】
複数の選手それぞれに対応づけて、当該選手に関するオブジェクトに付与されたオブジェクトＩＤを記憶する記憶部を備えたコンピュータに、各プレーヤチームの所属選手を管理するチーム対戦のゲームを実行するためのプログラムであって、
プレーヤ端末からの操作入力に従って前記オブジェクトＩＤの使用登録要求を受け付ける受付手段、
前記受付手段により受け付けられたオブジェクトＩＤが、既に登録済みであった場合には使用登録を不許可とし、未登録であった場合には使用登録を許可として、各オブジェクトＩＤの使用登録の有無を管理する登録管理手段、
前記登録管理手段により使用登録されたオブジェクトＩＤに対応する選手を、プレーヤチームの所属選手とすることで、各プレーヤチームの所属選手を管理する所属選手管理手段、
各プレーヤチームについて、当該プレーヤチームの各所属選手の使用登録の重複数に基づき、前記ゲームでの当該プレーヤチームにおける当該所属選手の能力パラメータを変更するパラメータ変更処理を実行するパラメータ変更手段、
として前記コンピュータを機能させるためのプログラム。
【請求項１】
チーム対戦のゲームを実行するための各プレーヤチームの所属選手を管理するコンピュータシステムであって、
複数の選手それぞれに対応づけて、当該選手に関するオブジェクトに付与されたオブジェクト固有のＩＤ（以下「オブジェクトＩＤ」という。）を記憶する記憶手段と、
プレーヤ端末からの操作入力に従って前記オブジェクトＩＤの使用登録要求を受け付ける受付手段と、
前記受付手段により受け付けられたオブジェクトＩＤが、既に登録済みであった場合には使用登録を不許可とし、未登録であった場合には使用登録を許可として、各オブジェクトＩＤの使用登録の有無を管理する登録管理手段と、
前記登録管理手段により使用登録されたオブジェクトＩＤに対応する選手を、プレーヤチームの所属選手とすることで、各プレーヤチームの所属選手を管理する所属選手管理手段と、
各プレーヤチームについて、当該プレーヤチームの各所属選手の使用登録の重複数に基づき、前記ゲームでの当該プレーヤチームにおける当該所属選手の能力パラメータを変更するパラメータ変更処理を実行するパラメータ変更手段と、
を備えたコンピュータシステム。
【請求項２】
前記所属選手管理手段は、前記プレーヤチームの所属選手として、能力パラメータの値が前記使用登録による所属選手より劣るように設定されたレンタル選手を管理し、当該レンタル選手と前記使用登録されたオブジェクトＩＤに対応する選手とが同一選手であった場合に、当該レンタル選手を所属選手から除外するレンタル選手管理手段を有する、
請求項１に記載のコンピュータシステム。
【請求項３】
前記ゲームの実行ルールとして同一選手の重複登録の可否を設定する重複登録可否設定手段を更に備えた、
請求項１又は２に記載のコンピュータシステム。
【請求項４】
複数の選手それぞれに対応づけて、当該選手に関するオブジェクトに付与されたオブジェクトＩＤを記憶する記憶部を備えたコンピュータに、各プレーヤチームの所属選手を管理するチーム対戦のゲームを実行するためのプログラムであって、
プレーヤ端末からの操作入力に従って前記オブジェクトＩＤの使用登録要求を受け付ける受付手段、
前記受付手段により受け付けられたオブジェクトＩＤが、既に登録済みであった場合には使用登録を不許可とし、未登録であった場合には使用登録を許可として、各オブジェクトＩＤの使用登録の有無を管理する登録管理手段、
前記登録管理手段により使用登録されたオブジェクトＩＤに対応する選手を、プレーヤチームの所属選手とすることで、各プレーヤチームの所属選手を管理する所属選手管理手段、
各プレーヤチームについて、当該プレーヤチームの各所属選手の使用登録の重複数に基づき、前記ゲームでの当該プレーヤチームにおける当該所属選手の能力パラメータを変更するパラメータ変更処理を実行するパラメータ変更手段、
として前記コンピュータを機能させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【公開番号】特開２０１１−２２９８９８（Ｐ２０１１−２２９８９８Ａ）
【公開日】平成２３年１１月１７日（２０１１．１１．１７）
【国際特許分類】
【出願番号】特願２０１０−２２８１１２（Ｐ２０１０−２２８１１２）
【出願日】平成２２年１０月８日（２０１０．１０．８）
【分割の表示】特願２０１０−１０１７０６（Ｐ２０１０−１０１７０６）の分割
【原出願日】平成２２年４月２７日（２０１０．４．２７）
【特許番号】特許第４６４２９３３号（Ｐ４６４２９３３）
【特許公報発行日】平成２３年３月２日（２０１１．３．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＱＲコード
【出願人】（０００１３４８５５）株式会社バンダイナムコゲームス (1,157)
【出願人】（０００１３５７４８）株式会社バンダイ (246)
【Ｆターム（参考）】
【公開日】平成２３年１１月１７日（２０１１．１１．１７）
【国際特許分類】
【出願日】平成２２年１０月８日（２０１０．１０．８）
【分割の表示】特願２０１０−１０１７０６（Ｐ２０１０−１０１７０６）の分割
【原出願日】平成２２年４月２７日（２０１０．４．２７）
【特許番号】特許第４６４２９３３号（Ｐ４６４２９３３）
【特許公報発行日】平成２３年３月２日（２０１１．３．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＱＲコード
【出願人】（０００１３４８５５）株式会社バンダイナムコゲームス (1,157)
【出願人】（０００１３５７４８）株式会社バンダイ (246)
【Ｆターム（参考）】
[ Back to top ]