(57)【特許請求の範囲】
【請求項１】
ゲーム画像を生成するゲームシステムであって、
複数のキャラクタにより構成される複数のノーマルチームと、当該複数のノーマルチームから選出された複数のキャラクタにより構成されるスペシャルチームとの中からゲームプレイに使用されるチームを選択するためのチーム選択手段と、
選択されたチームを用いてプレーヤがゲームプレイするためのゲーム演算を行うゲーム演算手段と、
前記ノーマルチームの構成キャラクタの中から最も活躍したキャラクタを決定するための指標データを記憶する指標データ記憶手段と、
前記指標データに基づいて、所定時点までのゲームプレイにおいて最も活躍したキャラクタを決定するとともに、最も活躍したキャラクタに活躍ポイントを付与するゲーム結果演算手段と、
前記活躍ポイントに基づいて、前記スペシャルチームを構成する所与のキャラクタを前記活躍ポイントを付与されたキャラクタに変更するか否かを判定し、その判定結果に基づいて変更するキャラクタ変更手段と、
を含むことを特徴とするゲームシステム。
【請求項２】
請求項１において、
前記ゲーム結果演算手段が、
前記指標データに基づいて、１ゲームの終了を条件としてゲームプレイにおいて最も活躍したキャラクタを決定するとともに、最も活躍したキャラクタに活躍ポイントを付与することを特徴とするゲームシステム。
【請求項３】
請求項１又は２のいずれかにおいて、
前記キャラクタには、属性データが設定されており、
前記キャラクタ変更手段が、
前記活躍ポイントに基づいて、前記活躍ポイントを付与されたキャラクタと同一の属性データが設定された前記スペシャルチームの構成キャラクタを、前記活躍ポイントを付与されたキャラクタに変更するか否かを判定し、その判定結果に基づいて変更することを特徴とするゲームシステム。
【請求項４】
請求項１乃至３のいずれかにおいて、
前記ノーマルチームの構成キャラクタに付与された前記活躍ポイントを累積して集計する処理を行うデータ集計手段を更に含み、
前記キャラクタ変更手段が、
前記活躍ポイントの集計結果に基づいて、前記スペシャルチームの構成キャラクタを前記ノーマルチームの構成キャラクタに変更するか否かを判定し、その判定結果に基づいて変更することを特徴とするゲームシステム。
【請求項５】
請求項４において、
前記データ集計手段が、
所与のリミット値を限度として、前記活躍ポイントを累積して集計する処理を行うことを特徴とするゲームシステム。
【請求項６】
請求項１乃至３のいずれかにおいて、
前記ノーマルチームの構成キャラクタに付与された前記活躍ポイントに代えて、キャラクタの識別データをデータ蓄積手段の記憶領域の所定位置から一定の順序で記憶させるとともに、全ての記憶領域に前記識別データを記憶させたことを条件に、再度、前記所定位置から一定の順序で前記識別データを記憶させる処理を行うデータ蓄積処理手段と、
蓄積された前記識別データを集計する処理を行うデータ集計手段とを更に含み、
前記キャラクタ変更手段が、
前記識別データの集計結果に基づいて、前記スペシャルチームの構成キャラクタを前記ノーマルチームの構成キャラクタに変更するか否かを判定し、その判定結果に基づいて変更することを特徴とするゲームシステム。
【請求項７】
請求項１乃至３のいずれかにおいて、
前記ノーマルチームの構成キャラクタに付与された前記活躍ポイントに代えて、当該キャラクタの識別データ及び蓄積時間データをデータ蓄積手段に蓄積させる処理を行うデータ蓄積処理手段と、
前記蓄積時間データに基づき所定の蓄積時間以前の前記識別データを除外して、蓄積された前記識別データを集計する処理を行うデータ集計手段とを更に含み、
前記キャラクタ変更手段が、
前記識別データの集計結果に基づいて、前記スペシャルチームの構成キャラクタを前記ノーマルチームの構成キャラクタに変更するか否かを判定し、その判定結果に基づいて変更することを特徴とするゲームシステム。
【請求項８】
請求項６又は７のいずれかにおいて、
前記データ集計手段が、
蓄積されたデータを所与の期間毎に集計する処理を行うことを特徴とするゲームシステム。
【請求項９】
サーバと複数のゲーム端末とを含み、前記サーバと前記複数のゲーム端末とがネットワークを介して通信可能なゲームシステムであって、
前記サーバが、
前記複数のゲーム端末から受信したゲーム結果を累積して集計する処理を行うデータ集計手段と、
ゲーム結果の集計結果を前記複数のゲーム端末に送信する通信制御手段とを含み、
前記複数のゲーム端末の各ゲーム端末が、
複数のキャラクタにより構成される複数のノーマルチームと、当該複数のノーマルチームから選出された複数のキャラクタにより構成されるスペシャルチームとの中からゲームプレイに使用されるチームを選択するためのチーム選択手段と、
選択されたチームを用いてプレーヤがゲームプレイするためのゲーム演算を行うゲーム演算手段と、
前記ノーマルチームを用いたゲームプレイでのゲーム結果を演算するゲーム結果演算手段と、
演算されたゲーム結果を前記サーバに送信する通信制御手段と、
前記サーバから受信したゲーム結果の集計結果に基づいて、前記スペシャルチームの構成キャラクタを前記ノーマルチームの構成キャラクタに変更するか否かを判定し、その判定結果に基づいて変更するキャラクタ変更手段とを含むことを特徴とするゲームシステム。
【請求項１０】
コンピュータにより情報の読み取りが可能な情報記憶媒体であって、
複数のキャラクタにより構成される複数のノーマルチームと、当該複数のノーマルチームから選出された複数のキャラクタにより構成されるスペシャルチームとの中からゲームプレイに使用されるチームを選択するためのチーム選択手段と、
選択されたチームを用いてプレーヤがゲームプレイするためのゲーム演算を行うゲーム演算手段と、
前記ノーマルチームの構成キャラクタの中から最も活躍したキャラクタを決定するための指標データを記憶する指標データ記憶手段と、
前記指標データに基づいて、所定時点までのゲームプレイにおいて最も活躍したキャラクタを決定するとともに、最も活躍したキャラクタに活躍ポイントを付与するゲーム結果演算手段と、
前記活躍ポイントに基づいて、前記スペシャルチームを構成する所与のキャラクタを前記活躍ポイントを付与されたキャラクタに変更するか否かを判定し、その判定結果に基づいて変更するキャラクタ変更手段としてコンピュータを機能させるためのプログラムを記憶することを特徴とする情報記憶媒体。
【請求項１１】
請求項１０において、
前記ゲーム結果演算手段が、
前記指標データに基づいて、１ゲームの終了を条件としてゲームプレイにおいて最も活躍したキャラクタを決定するとともに、最も活躍したキャラクタに活躍ポイントを付与することを特徴とする情報記憶媒体。
【請求項１２】
請求項１０又は１１のいずれかにおいて、
前記キャラクタには、属性データが設定されており、
前記キャラクタ変更手段が、
前記活躍ポイントに基づいて、前記活躍ポイントを付与されたキャラクタと同一の属性データが設定された前記スペシャルチームの構成キャラクタを、前記活躍ポイントを付与されたキャラクタに変更するか否かを判定し、その判定結果に基づいて変更することを特徴とする情報記憶媒体。
【請求項１３】
請求項１０乃至１２のいずれかにおいて、
前記ノーマルチームの構成キャラクタに付与された前記活躍ポイントを累積して集計する処理を行うデータ集計手段として更にコンピュータを機能させるプログラムを記憶し、
前記キャラクタ変更手段が、
前記活躍ポイントの集計結果に基づいて、前記スペシャルチームの構成キャラクタを前記ノーマルチームの構成キャラクタに変更するか否かを判定し、その判定結果に基づいて変更することを特徴とする情報記憶媒体。
【請求項１４】
請求項１３において、
前記データ集計手段が、
所与のリミット値を限度として、前記活躍ポイントを累積して集計する処理を行うことを特徴とする情報記憶媒体。
【請求項１５】
請求項１０乃至１２のいずれかにおいて、
前記ノーマルチームの構成キャラクタに付与された前記活躍ポイントに代えて、キャラクタの識別データをデータ蓄積手段の記憶領域の所定位置から一定の順序で記憶させるとともに、全ての記憶領域に前記識別データを記憶させたことを条件に、再度、前記所定位置から一定の順序で前記識別データを記憶させる処理を行うデータ蓄積処理手段と、
蓄積された前記識別データを集計する処理を行うデータ集計手段として更にコンピュータを機能させるプログラムを記憶し、
前記キャラクタ変更手段が、
前記識別データの集計結果に基づいて、前記スペシャルチームの構成キャラクタを前記ノーマルチームの構成キャラクタに変更するか否かを判定し、その判定結果に基づいて変更することを特徴とする情報記憶媒体。
【請求項１６】
請求項１０乃至１２のいずれかにおいて、
前記ノーマルチームの構成キャラクタに付与された前記活躍ポイントに代えて、当該キャラクタの識別データ及び蓄積時間データをデータ蓄積手段に蓄積させる処理を行うデータ蓄積処理手段と、
前記蓄積時間データに基づき所定の蓄積時間以前の前記識別データを除外して、蓄積された前記識別データを集計する処理を行うデータ集計手段として更にコンピュータを機能させるプログラムを記憶し、
前記キャラクタ変更手段が、
前記識別データの集計結果に基づいて、前記スペシャルチームの構成キャラクタを前記ノーマルチームの構成キャラクタに変更するか否かを判定し、その判定結果に基づいて変更することを特徴とする情報記憶媒体。
【請求項１７】
請求項１５又は１６のいずれかにおいて、
前記データ集計手段が、
蓄積されたデータを所与の期間毎に集計する処理を行うことを特徴とする情報記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ゲームシステム及び情報記憶媒体に関する。
【０００２】
【背景技術及び発明が解決しようとする課題】
従来より、画面上に映し出されたゲーム画像を見ながら野球を擬似的に楽しむことができるゲームシステムが人気を博している。
【０００３】
このゲームシステムでは、プレーヤは、まず、複数のチーム（球団）の中から自身が所望するチームを選択する。そして、守備時においては、選択したチームの構成キャラクタである投手キャラクタを操作してピッチングを行わせ、相手プレーヤやコンピュータが操作する打者キャラクタとの対戦を楽しむ。また、攻撃時においては、選択したチームの構成キャラクタである打者キャラクタを操作して打撃を行わせ、相手プレーヤやコンピュータが操作する投手キャラクタとの対戦を楽しむ。
【０００４】
しかしながら、これまでのゲームシステムにおいては、プレーヤが選択可能なチームの構成キャラクタ（メンバ）が出荷時のままで固定的に設定されていた。従って、プレーヤがどのゲームシステムでプレイしても、プレーヤが選択したチームの構成キャラクタは同一なものとなってしまい、チームに対するプレーヤの愛着度を今一つ高めることができなかった。
【０００５】
例えば、プレーヤが選択可能なチームの中には、各チームの優秀な選手を集めたオールスターチーム（広義にはスペシャルチーム）と呼ばれるものがある。そして、プレーヤが、例えばチームＡのファンであった場合を考える。この場合には、プレーヤは、なるべく多くのチームＡのキャラクタが、オールスターチームのメンバになることを望むことになる。しかしながら、これまでのゲームシステムにおいては、オールスターチームの構成キャラクタが出荷時のままで固定的に設定されていた。従って、プレーヤは、例えば、自身が嫌いなチームのキャラクタが多く選出されているオールスターチームを用いてゲームをプレイせざるを得なかった。このため、せっかく用意されたオールスターチームがプレーヤにより選択されなくなる事態が生じ、ゲームの面白味や人気度を低める結果となっていた。
【０００６】
特に、プレーヤがどのチーム（現実世界のチーム）を好むかは、地域によって差がある。例えば、東京では、東京を本拠とするチームＧに人気があり、大阪では、大阪を本拠とするチームＴに人気がある。従って、ゲームの面白味や人気度を高めるためには、東京のアミューズメント施設（ゲームセンター等）に設置されるゲームシステムのオールスターチームでは、チームＧのキャラクタが多く選出されていることが望まれ、大阪のアミューズメント施設に設置されるゲームシステムのオールスターチームでは、チームＴのキャラクタが多く選出されていることが望まれる。
【０００７】
しかしながら、これまでのゲームシステムでは、オールスターチームの構成キャラクタは、出荷時のままで固定的に設定されていた。従って、ゲームシステムが大阪に設置されているのにもかかわらず、オールスターチームの構成キャラクタの多くがチームＧのキャラクタになってしまう等の事態が生じていた。このように、従来のゲームシステムでは、ゲームシステムの地域密着度を今一つ高めることができないという問題点もあった。
【０００８】
本発明は、以上のような課題を解決するためになされたものであり、その目的とするところは、チーム、特にスペシャルチームに対するプレーヤの愛着度を効果的に高めることができるゲームシステム及び情報記憶媒体を提供することにある。
【０００９】
また本発明の他の目的は、ゲームシステムの地域密着度を高めることができるゲームシステム及び情報記憶媒体を提供することにある。
【００１０】
【課題を解決するための手段】
上記課題を解決するために、本発明は、ゲーム画像を生成するゲームシステムであって、ゲームプレイに使用されるチームを選択するための手段と、選択されたチームを用いてプレーヤがゲームプレイするためのゲーム演算を行う手段と、ゲームプレイでのゲーム結果を演算する手段と、演算されたゲーム結果に基づいて、プレーヤが選択可能なチームの構成キャラクタを順次入れ替える手段とを含むことを特徴とする。また本発明に係る情報記憶媒体は、コンピュータにより使用可能な情報記憶媒体であって、上記手段を実現（実行）するための情報（プログラム）を含むことを特徴とする。また本発明に係るプログラムは、コンピュータにより使用可能なプログラムであって、上記手段を実現（実行）するためのプログラムであることを特徴とする。
【００１１】
本発明によれば、例えばプレーヤは選択画面等を用いて使用チームを選択し、そのチームを用いてゲームプレイを行う。すると、そのゲームプレイでのゲーム結果が演算される。そして、演算されたゲーム結果に基づいて、プレーヤが選択可能なチームの構成キャラクタが入れ替わる（構成キャラクタが変更される）。従って、本発明によれば、チームの構成キャラクタの入れ替え処理に、ゲームプレイでのゲーム結果を反映できるようになる。従って、チームの構成キャラクタが画一的になるのが防止され、チームへのプレーヤの愛着度を増すことができる。
【００１２】
なお、使用チームの選択方法はチーム選択画面等を用いることが望ましいが、これに限定されるものではない。また、演算されるゲーム結果としては、キャラクタの活躍度などが特に望ましいが、これ以外にも勝敗、順位、得点等、種々のものを考えることができる。また、構成キャラクタの入れ替え対象となるチームは、プレーヤがゲームプレイに使用したチームでもよいし、プレーヤがゲームプレイに使用したチーム以外のチーム（スペシャルチーム等）でもよい。
【００１３】
また本発明に係るゲームシステム、情報記憶媒体及びプログラムは、ノーマルチームを用いたゲームプレイでのゲーム結果に基づいて、スペシャルチームの構成キャラクタが順次入れ替わることを特徴とする。このようにすることで、スペシャルチームの構成キャラクタの入れ替え処理に、ゲームプレイでのゲーム結果を反映できるようになり、スペシャルチーム（オールスターチーム等）の構成キャラクタのバラエティ度を増すことができるようになる。
【００１４】
また本発明に係るゲームシステム、情報記憶媒体及びプログラムは、ノーマルチームを用いたゲームプレイでの１ゲームの終了を条件としてキャラクタに活躍ポイントが与えられ、与えられた活躍ポイントに基づいてスペシャルチームの構成キャラクタが入れ替わることを特徴とする。このようにすれば、プレーヤは、１ゲームが終了するまでゲームプレイを続行するようになり、継続プレイの効果的な動機づけをプレーヤに与えることができるようになる。
【００１５】
また本発明に係るゲームシステム、情報記憶媒体及びプログラムは、同一ポジションのキャラクタ同士が入れ替わることを特徴とする。このようにすれば、本来は例えば第１のポジション（守備位置、配置位置）に割り当てられるべきキャラクタが第２のポジションに割り当てられてしまいプレーヤが不自然さを感じる事態を防止できるようになる。
【００１６】
また本発明に係るゲームシステム、情報記憶媒体及びプログラムは、ゲームプレイにおける各キャラクタに関するデータがゲーム結果として蓄積され、蓄積されたデータの集計結果に基づいてチームの構成キャラクタが入れ替わることを特徴とする。このようにすれば、チームの構成キャラクタが統計的に決められるようになり、ゲームシステムの地域密着度の向上等を図れるようになる。
【００１７】
また本発明に係るゲームシステム、情報記憶媒体及びプログラムは、蓄積される前記データが、キャラクタの活躍ポイント、活躍したキャラクタの識別データ、及び蓄積時間データの少なくとも１つを含むことを特徴とする。例えば、キャラクタの活躍ポイントや活躍したキャラクタの識別データを蓄積し、蓄積された活躍ポイントや識別データの集計結果に基づいて、チームの構成キャラクタを入れ替えれば、より活躍度の高いキャラクタをチームの構成キャラクタとして登録することが可能になる。また、蓄積時間データ、即ちデータを蓄積した時間（年、日、時等）を蓄積するようにすれば、この蓄積時間データを用いて、データの削除処理を行ったり、所与の期間毎の集計処理を行ったりすることが可能になる。
【００１８】
また本発明に係るゲームシステム、情報記憶媒体及びプログラムは、前記活躍ポイントの増加の制限処理、前記識別データの記憶領域の制限処理、及び前記蓄積時間データを用いた蓄積データの削除処理の少なくとも１つが行われることを特徴とする。このようにすれば、データの蓄積に必要な記憶容量の節約を図ることができると共に、蓄積データが無制限に増加する事態を防止できるようになる。
【００１９】
また本発明に係るゲームシステム、情報記憶媒体及びプログラムは、蓄積されたデータが所与の期間毎に集計されることを特徴とする。このようにすれば、所与の期間毎にデータを蓄積しチームの構成キャラクタを入れ替えることが可能になり、より変化に富んだ入れ替えを実現できるようになる。
【００２０】
また本発明に係るゲームシステム、情報記憶媒体及びプログラムは、ゲームプレイにおける各キャラクタに関するデータがホスト装置に蓄積され、該ホスト装置が、蓄積されたデータを集計することを特徴とする。このようにすれば、より広い範囲のプレーヤのゲーム結果を、チームの構成キャラクタの入れ替え処理に反映できるようになる。
【００２１】
【発明の実施の形態】
以下、本発明の好適な実施形態について図面を用いて説明する。なお以下では、本発明を野球ゲームに適用した場合を例にとり説明するが、本発明はこれに限定されず、種々のゲームに適用できる。
【００２２】
１．構成
図１に、本実施形態のブロック図の一例を示す。なお同図において本実施形態は、少なくとも処理部１００を含めばよく（或いは処理部１００と記憶部１４０、或いは処理部１００と記憶部１４０と情報記憶媒体１５０を含めばよく）、それ以外のブロック（例えば操作部１３０、画像生成部１６０、表示部１６２、音生成部１７０、音出力部１７２、通信部１７４、Ｉ／Ｆ部１７６、メモリーカード１８０等）については、任意の構成要素とすることができる。
【００２３】
ここで処理部１００は、システム全体の制御、システム内の各ブロックへの命令の指示、ゲーム演算などの各種の処理を行うものであり、その機能は、ＣＰＵ（ＣＩＳＣ型、ＲＩＳＣ型）、ＤＳＰ、或いはＡＳＩＣ（ゲートアレイ等）などのハードウェアや、所与のプログラム（ゲームプログラム）により実現できる。
【００２４】
操作部１３０は、プレーヤが操作情報を入力するためのものであり、その機能は、レバー、ボタンなどのハードウェアにより実現できる。
【００２５】
記憶部１４０は、処理部１００、画像生成部１６０、音生成部１７０、通信部１７４、Ｉ／Ｆ部１７６などのワーク領域となるもので、その機能はＲＡＭなどのハードウェアにより実現できる。
【００２６】
情報記憶媒体（コンピュータにより使用可能な記憶媒体）１５０は、プログラムやデータなどの情報を格納するものであり、その機能は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いは半導体メモリ（ＲＯＭ）などのハードウェアにより実現できる。処理部１００は、この情報記憶媒体１５０に格納される情報に基づいて本発明（本実施形態）の種々の処理を行う。即ち情報記憶媒体１５０には、本発明（本実施形態）の手段（特に処理部１００、記憶部１４０に含まれるブロック）を実現（実行）するための種々の情報（プログラム、データ）が格納される。
【００２７】
なお、情報記憶媒体１５０に格納される情報の一部又は全部は、システムへの電源投入時等に記憶部１４０に転送されることになる。また情報記憶媒体１５０に記憶される情報は、本発明の処理を行うためのプログラムコード、画像情報、音情報、表示物の形状情報、テーブルデータ、リストデータ、プレーヤ情報や、本発明の処理を指示するための情報、その指示に従って処理を行うための情報等の少なくとも１つを含むものである。
【００２８】
画像生成部１６０は、処理部１００からの指示等にしたがって、各種の画像を生成し表示部１６２に出力するものであり、その機能は、画像生成用ＡＳＩＣ、ＣＰＵ、或いはＤＳＰなどのハードウェアや、所与のプログラム（画像生成プログラム）、画像情報により実現できる。
【００２９】
音生成部１７０は、処理部１００からの指示等にしたがって、各種の音を生成し音出力部１７２に出力するものであり、その機能は、音生成用ＡＳＩＣ、ＣＰＵ、或いはＤＳＰなどのハードウェアや、所与のプログラム（音生成プログラム）、音情報（波形データ等）により実現できる。
【００３０】
通信部１７４は、外部装置（例えばホスト装置や他のゲームシステム）との間で通信を行うための各種の制御を行うものであり、その機能は、通信用ＡＳＩＣ、或いはＣＰＵなどのハードウェアや、所与のプログラム（通信プログラム）により実現できる。
【００３１】
なお本発明（本実施形態）の処理を実現するための情報は、ホスト装置（サーバー）が有する情報記憶媒体からネットワーク、通信部１７４を介して情報記憶媒体１５０に配信するようにしてもよい。このようなホスト装置（サーバー）の情報記憶媒体の使用も本発明の範囲内に含まれる。
【００３２】
また処理部１００の機能の一部又は全部を、画像生成部１６０、音生成部１７０、又は通信部１７４の機能により実現するようにしてもよい。或いは、画像生成部１６０、音生成部１７０、又は通信部１７４の機能の一部又は全部を、処理部１００の機能により実現するようにしてもよい。
【００３３】
Ｉ／Ｆ部１７６は、処理部１００からの指示等にしたがってメモリーカード（広義には、携帯型ゲーム機などを含む携帯型情報記憶装置）１８０との間で情報交換を行うためのインターフェースとなるものであり、その機能は、メモリーカードを挿入するためのスロットや、データ書き込み・読み出し用コントローラＩＣなどにより実現できる。なお、メモリーカード１８０との間の情報交換を赤外線などの無線を用いて実現する場合には、Ｉ／Ｆ部１７６の機能は、半導体レーザ、赤外線センサーなどのハードウェアにより実現できる。
【００３４】
処理部１００は、ゲーム演算部１１０を含む。
【００３５】
ここでゲーム演算部１１０は、コイン（代価）の受け付け処理、ゲームモードの設定処理、ゲームの進行処理、選択画面の設定処理、移動体（キャラクタ、ボール等）の位置や方向を決める処理、視点位置や視線方向を決める処理、移動体のモーションを再生する処理、オブジェクト空間へオブジェクトを配置する処理、ヒットチェック処理、ゲーム結果（成果、成績）を演算する処理、複数のプレーヤが共通のゲーム空間でプレイするための処理、或いはゲームオーバー処理などの種々のゲーム演算処理を、操作部１３０からの操作情報、メモリーカード１８０からの情報、ゲームプログラムなどに基づいて行う。
【００３６】
ゲーム演算部１１０は、チーム選択部１１２、ゲーム結果演算部１１４、キャラクタ入れ替え部１２０を含む。
【００３７】
ここで、チーム選択部１１２は、ゲームプレイに使用されるチームを選択するための処理を行う。より具体的には、例えば、チームの選択画面を表示する処理や、この選択画面でのプレーヤの選択指示を受け付ける処理などを行う。
【００３８】
ゲーム結果演算部１１４は、ゲームプレイでのゲーム結果を演算する処理を行う。より具体的には、例えば、プレーヤがゲームプレイしたゲーム（試合）におけるキャラクタ（選手）の活躍度（印象度）を演算する処理を行う。なお、演算されるゲーム結果としては、上記の活躍度以外にも、例えば、勝敗、順位、得点、命中率、倒した相手の数、被弾数、アシスト回数、敵陣侵入回数、迎撃回数、ラップタイム、周回回数、残り体力、打率、防御率、ゴール数、奪った国及びその数、引き抜いた武将及びその数、獲得したアイテム及びその数、クイズの正当数及び正答率、クリア時間、与えられた任務の成功の可否等、種々のものを考えることができる。
【００３９】
キャラクタ入れ替え部１２０は、演算されたゲーム結果に基づいて、プレーヤが選択可能なチームの構成キャラクタ（メンバ）を順次入れ替える処理（構成キャラクタを変更する処理）を行う。例えば、演算されたゲーム結果に基づいて選択されたキャラクタが、チームの構成キャラクタになるように、入れ替え処理を行う。より具体的には、ノーマルチームを用いたゲームプレイでのゲーム結果に基づいて、オールスターチーム（広義にはスペシャルチーム）の構成キャラクタを入れ替える。この場合、例えば、ノーマルチームを用いたゲームプレイにおいて、最も活躍度が高かったキャラクタが、オールスターチームの構成キャラクタになるようにする。
【００４０】
なお、構成キャラクタの入れ替え処理を行う場合には、同一ポジション（守備位置、配置）のキャラクタ同士を入れ替えることが望ましい。即ち、そのキャラクタと同一ポジションのキャラクタを入れ替え対象として選択する。例えば、オールスターチームのサードのキャラクタを入れ替える場合には、同じサードのポジションのキャラクタを入れ替え対象として選択するようにする。
【００４１】
ゲーム結果演算部１１４は、データ蓄積処理部１１６、データ集計部１１８を含む。
【００４２】
ここで、データ蓄積処理部１１６は、ゲームプレイにおける各キャラクタに関するデータ（キャラクタの活躍ポイント、活躍したキャラクタの識別データ、蓄積時間データ等）を、記憶部１４０の中のデータ蓄積部１４２に蓄積するための処理を行う。またデータ集計部１１８は、データ蓄積部１４２に蓄積されたデータを集計するための処理を行う。そして、キャラクタ入れ替え処理部１２０は、データ集計部１１８での集計結果に基づいて、チームの構成キャラクタの入れ替え処理を行うことになる。より具体的には、ノーマルチームを用いたゲームプレイにおいて活躍度の高かったキャラクタに関するデータが、ゲーム結果としてデータ蓄積部１４２に蓄積され、蓄積されたデータの集計結果に基づいて、オールスターチームの構成キャラクタの入れ替え処理が行われるようになる。
【００４３】
なお、本実施形態のゲームシステムでは、１人のプレーヤがプレイするシングルプレーヤモードによるゲームプレイと、複数のプレーヤがプレイするマルチプレーヤモードによるゲームプレイの両方が可能になっている。
【００４４】
また複数のプレーヤがプレイする場合に、これらの複数のプレーヤに提供するゲーム画像やゲーム音を、１つの端末を用いて生成してもよいし、ネットワーク（伝送ライン、通信回線）などで接続された複数の端末を用いて生成してもよい。
【００４５】
２．本実施形態の特徴
本実施形態では、まず、図２に示すようなチーム選択画面がプレーヤに表示される。プレーヤは、この選択画面を見ながら、チームＧ、Ｔ、Ｂ、Ｄ、Ｃ、Ｓ、ＡＬＬＸ、Ｈ、Ｌ、Ｍ、Ｆ、Ｏ、Ｒ、ＡＬＬＹの中から１つのチームを選択してゲームプレイを行う。
【００４６】
ここで、チームＡＬＬＸは、ノーマルチームＧ、Ｔ、Ｂ、Ｄ、Ｃ、Ｓから選出されたキャラクタにより構成されるオールスターチーム（広義にはスペシャルチーム）である。また、チームＡＬＬＹは、ノーマルチームＨ、Ｌ、Ｍ、Ｆ、Ｏ、Ｒから選出されたキャラクタにより構成されるオールスターチームである。
【００４７】
オールスターチームＡＬＬＸの構成キャラクタは、例えば図３のＡ１に示すように初期設定されている。
【００４８】
即ち、初期設定時（ゲームシステムの出荷時）においてＡＬＬＸは、キャラクタＢ６、Ｄ４、Ｇ３、Ｇ８、Ｇ９、Ｓ２、Ｔ５、Ｃ７、Ｇ１等により構成されている（なお、ＡＬＬＸは、これらのキャラクタ以外にも、代打要員、守備要員のキャラクタや、他の先発要員のキャラクタや、中継ぎや救援要員のキャラクタを含む）。
【００４９】
ここで、Ｂ６は、チームＢのショート（６）のキャラクタを意味する。また、Ｄ４は、チームＤのセカンド（４）のキャラクタを意味し、Ｇ３は、チームＧのファースト（３）のキャラクタを意味する。Ｇ８、Ｇ９、Ｓ２、Ｔ５、Ｃ７、Ｇ１についても同様である。この初期設定時のキャラクタについては、現実世界での野球選手の前年度の成績や、前年度のオールスター投票の結果等に基づいて、ゲームシステムのメーカ側が予め設定しておく（ＲＯＭ、ＤＶＤ等に書き込んでおく）。
【００５０】
さて、図４に示すように、プレーヤが例えばノーマルチームＴを選択してゲームプレイを行い、そのゲーム（試合）においてキャラクタＴ８が活躍し、ＭＶＰになった場合を考える。この場合に本実施形態では、図３のＡ２に示すように、キャラクタＴ８のＭＶＰポイント（広義には活躍ポイント）が例えば１ポイントだけ加算される。そして、ＭＶＰポイントを集計した結果、同一ポジションのキャラクタの中でキャラクタＴ８のＭＶＰポイントが最も高いと判断された場合には、キャラクタＴ８がオールスターチームＡＬＬＸの構成キャラクタとして選出され登録される。即ち、図３のＡ３、Ａ４に示すように、それまでＡＬＬＸの構成キャラクタであったキャラクタＧ８が、同一ポジションのキャラクタＴ８と入れ替わる。
【００５１】
以上のようにすることで、プレーヤのゲーム結果に応じて、ＡＬＬＸ（或いはＯＬＬＹ）の構成キャラクタが順次入れ替わるようになり、オールスターチームの構成キャラクタが画一的になるのを効果的に防止できるようになる。
【００５２】
即ち、従来のゲームシステムにおいては、オールスターチームの構成キャラクタは出荷時のままで固定的に設定されていた（図３のＡ１参照）。従って、東京のプレーヤがゲームプレイした場合でも、大阪のプレーヤがゲームプレイした場合でも、オールスターチームの構成キャラクタは常に同一になってしまう。
【００５３】
しかしながら、大阪に住むプレーヤは、大阪を本拠とするチームＴのキャラクタ（選手）が多くを占めるオールスターチームを望むのが一般的である。ところが、初期設定時においては図３のＡ１に示すように、東京を本拠とするチームＧのキャラクタ（Ｇ３、Ｇ８、Ｇ９、Ｇ１）が、オールスターチームの構成キャラクタの多くを占めている。このため、大阪のプレーヤは、チームＴのキャラクタではなく自身が嫌いなチームＧのキャラクタが多くを占めるオールスターチームに対して愛着を持つことができず、せっかく用意されたオールスターチームがプレーヤにより選択されなくなるという事態が生じていた。
【００５４】
これに対して、本実施形態によれば、不特定多数のプレーヤのゲーム結果に基づいて、オールスターチームの構成キャラクタが順次入れ替わるため、上記の事態を効果的に防止できる。即ち、大阪に設置されるゲームシステムにおいては、大阪のプレーヤが多くプレイするため、大阪のチームＴの使用頻度（選択確率）が多くなる。このため、チームＴのキャラクタがＭＶＰになる確率が高くなり、図５（Ａ）に示すように、オールスターチームは、大阪のチームＴ（或いは関西のチームＤ、Ｃ）のキャラクタが多くを占めるようになる。この結果、大阪のプレーヤは、このオールスターチームに愛着を持てるようになる。
【００５５】
一方、東京に設置されるゲームシステムにおいては、東京のチームＧの使用頻度が多くなるため、チームＧのキャラクタがＭＶＰになる確率が高くなる。従って、図５（Ｂ）に示すように、オールスターチームは、東京のチームＧ（或いは関東のチームＳ、Ｂ）のキャラクタが多くを占めるようになり、東京のプレーヤは、このオールスターチームに愛着を持てるようになる。
【００５６】
このように、本実施形態によれば、ゲームシステムの地域密着度を高めることが可能になり、各地域に応じた最適なゲームシステムを提供できるようになる。また、オールスターチームの構成キャラクタは、各店舗毎に異なるようになるため、店舗単位で特色を出すことができるようになる。
【００５７】
なお、本実施形態においては、ノーマルチームのゲームプレイにおいて１ゲーム（９イニング）が成立した場合に限り、キャラクタがＭＶＰを獲得できるようなっている（ノーマルチームを用いたゲームプレイでの１ゲームの終了を条件としてキャラクタに活躍ポイントが与えられる）。
【００５８】
例えば本実施形態では、１コインで３イニングのゲームプレイが可能であり、９イニングのゲームプレイを完了するためには３コインが必要になる。従って、図６（Ａ）に示すように、プレーヤが１コインしか支払わなかった場合には、プレーヤが応援するキャラクタＴ８が活躍しても、Ｔ８はＭＶＰを獲得できないことになる。一方、図６（Ｂ）に示すように、プレーヤが３コインを支払い１ゲームが終了した場合には、そのゲームで活躍したキャラクタＴ８はＭＶＰを獲得できるようになり、キャラクタＧ８と入れ替わってオールスターチームに登録される可能性が高まる。従って、プレーヤは、自身が好きなキャラクタＴ８がＭＶＰを獲得してオールスターチームに登録されるように、９イニングが終了するまでコインを投入してゲームプレイを続行するようになる。この結果、継続プレイに対する効果的な動機づけをプレーヤに与えることが可能になり、ゲームシステムの稼働率の向上を図れるようになる。
【００５９】
また、本実施形態においては、図３のＡ３、Ａ４に示すように、オールスターチームの構成キャラクタを入れ替える場合に、同一ポジション（守備位置、配置位置）のキャラクタ同士を入れ替えるようにしている。
【００６０】
例えば、本実施形態と異なる手法として、同一打順のキャラクタ同士を入れ替える手法も考えることができる。しかしながら、この手法によると、センタを守るべきキャラクタが例えばキャッチャーになってしまう等の事態が生じてしまい、プレーヤに不自然感を与える。即ち、この種のゲームでは、現実世界の選手を擬人化したキャラクタを使用することで、プレーヤの仮想現実感を高めている。従って、現実世界でセンターを守る選手を擬人化したキャラクタがキャッチャーになってしまうと、ゲームのリアル度が低まり、仮想現実感の向上を阻害してしまう。
【００６１】
本実施形態のように、同一ポジションのキャラクタ同士を入れ替えれば、センターを守るべきキャラクタは、同じくセンターを守るべき他のキャラクタと入れ替わるようになり、プレーヤに不自然感を与える事態を防止できるようになる。
【００６２】
さて、本実施形態では、各キャラクタが獲得したＭＶＰポイントを順次蓄積（プール）し、この蓄積されたＭＶＰポイントに基づいてキャラクタの入れ替え処理を行っている。従って、何度もＭＶＰになり、多くのＭＶＰポイントを獲得したキャラクタについては、入れ替わる確率が低くなる。即ち、オールスターチームの初期設定時の構成キャラクタであったＧ８が、ＭＶＰを例えば１回獲得したとする。すると、キャラクタＴ８は、ＭＶＰを２回獲得しない限りオールスターチームに登録されないことになる。同様に、キャラクタＧ８がＭＶＰを例えば１０回獲得すると、キャラクタＴ８はＭＶＰを１１回獲得しない限りオールスターチームに登録されないことになる。
【００６３】
このように蓄積されたＭＶＰポイント（広義にはキャラクタに関するデータ）に基づいてキャラクタの入れ替え処理を行うことで、現実世界におけるオールスター投票と同じ様にオールスターチームの構成キャラクタが決められるようになる。この結果、ゲームのリアル度を高めることができる。
【００６４】
また、蓄積されたＭＶＰポイントに基づいて入れ替え処理を行うことで、オールスターチームの構成キャラクタの選出に、多くのプレーヤのゲーム結果が反映されるようになる。この結果、ゲームシステムの地域密着度を更に高めることができる。即ち、例えば、ＭＶＰポイントを蓄積せずに、前回のゲームでＭＶＰを獲得したキャラクタをオールスターチームに登録する手法を採用したとする。この手法によると、大阪に設置されるゲームシステムにおいて、チームＧを好きなプレーヤが連続してたまたまゲームプレイした場合には、オールスターチームの多くをチームＧの構成キャラクタが占めるようになってしまう。従って、ゲームシステムの地域密着度が薄れてしまう。
【００６５】
これに対して、蓄積されたＭＶＰポイントに基づいて入れ替え処理を行う手法によれば、オールスターチームの構成キャラクタは統計的に決められるようになる。従って、大阪に設置されるゲームシステムにおいて、チームＧを好きなプレーヤが連続してたまたまゲームプレイしたような場合でも、オールスターチームの多くをチームＴの構成キャラクタが占めることになり、ゲームシステムの地域密着度を高めることができる。
【００６６】
３．本実施形態の処理
（１）第１の処理例
次に、本実施形態の第１の処理例について図７のフローチャートを用いて説明する。
【００６７】
まず、ゲーム（試合）が終了したか否かを判断し（ステップＶ１）、終了した場合には、そのゲームのＭＶＰのキャラクタを決定する（ステップＶ２）。この場合、例えば、勝利打点を記録したキャラクタ、サヨナラ安打やサヨナラホームランを打ったキャラクタ、完封勝利をしたキャラクタ、完全試合やノーヒットノーランを達成したキャラクタ、セーブポイントを記録したキャラクタなどがＭＶＰの候補となる。なお、野手部門と投手部門で別々にＭＶＰを決めるようにしてもよい。
【００６８】
次に、ＭＶＰとなったキャラクタのＭＶＰポイントに１をプラスする（ステップＶ３）。そして、蓄積されたＭＶＰポイントを例えばポジション別に集計し、集計結果に基づいて、ＭＶＰポイントが最も高いキャラクタを選択する（ステップＶ４）。そして、選択されたキャラクタをオールスターチームの構成キャラクタとして登録する（ステップＶ５）。
【００６９】
オールスターチームの構成キャラクタは例えば図８（Ａ）に示すように初期設定されている。しかしながら、ノーマルチームＴのゲームでキャラクタＴ８がＭＶＰポイントを獲得し、図８（Ｂ）に示すように、キャラクタＴ８のＭＶＰポイントが最も高いと判断されると、キャラクタＧ８の代わりにＴ８がオールスターチームに登録されるようになる。
【００７０】
なお、ＭＶＰポイント（活躍ポイント）を蓄積する際には、図８（Ｃ）に示すように、ＭＶＰポイントの増加を制限する処理を行うことが望ましい。より具体的には、ＭＶＰポイントが所与のリミット値を越えないように制限する。
【００７１】
このようにすれば、例えばキャラクタのＭＶＰポイントが無制限に増加し、ＭＶＰポイントの蓄積に必要な記憶容量が足りなくなってしまう等の事態を防止できる。
【００７２】
また、例えば、特定のチームばかりが使用され続けることによりその特定チームのキャラクタのＭＶＰポイントが過大に増加してしまい、オールスターチームの入れ替え処理が全く行われなくなってしまうという事態も防止できるようになる。
【００７３】
（２）第２の処理例
図９に本実施形態の第２の処理例についてのフローチャートを示す。図７では、ＭＶＰキャラクタのＭＶＰポイント（広義には活躍ポイント）を蓄積していたのに対して、図９では、ＭＶＰキャラクタのＩＤ（広義には識別データ）を蓄積している。
【００７４】
ゲームが終了し、そのゲームのＭＶＰのキャラクタが決定されると、ＭＶＰキャラクタのＩＤを現在のポインタ指示位置に記憶する（ステップＶ１１、Ｖ１２、Ｖ１３）。そして、図１０（Ａ）に示すように、ポインタを１つ進める（ステップＶ１４）。
【００７５】
次に、ＩＤ記憶（蓄積）領域が満杯か否かを判断し（ステップＶ１５）、満杯の場合には、図１０（Ｂ）、（Ｃ）に示すように、ポインタをＩＤ記憶領域の先頭に戻す（ステップＶ１６）。
【００７６】
次に、蓄積データを集計し、ＩＤの蓄積回数が最も多いキャラクタを選択し（ステップＶ１７）、選択されたキャラクタをオールスターチームの構成キャラクタとして登録する（ステップＶ１８）。例えば、キャラクタＴ８のＩＤの蓄積回数が最も多かった場合には、Ｔ８が選択され、オールスターチームに登録されることになる。一方、キャラクタＧ８のＩＤの蓄積回数が最も多かった場合には、Ｇ８が選択され、Ｇ８がオールスターチームに登録されることになる。
【００７７】
図９のように、ポインタを利用してＩＤ記憶領域を制限することで、ＩＤの蓄積に必要な記憶容量を節約できるようになり、ＩＤ記憶領域が無制限に増加してしまう事態を防止できるようになる。
【００７８】
（３）第３の処理例
図１１に本実施形態の第３の処理例についてのフローチャートを示す。図９では、ＭＶＰキャラクタのＩＤのみを蓄積していたのに対して、図１１では、ＭＶＰキャラクタのＩＤと共に日付（広義には蓄積時間データ）を蓄積している。
【００７９】
ゲームが終了し、そのゲームのＭＶＰのキャラクタが決定されると、図１２に示すように、ＭＶＰキャラクタのＩＤと、ＩＤを蓄積した日付を記憶する（ステップＶ２１、Ｖ２２、Ｖ２３）。そして、日付の古いデータがあるか否かを判断し（ステップＶ２４）、古いデータがあった場合には削除する（ステップＶ２５）。
【００８０】
次に、蓄積データを集計し、ＩＤの蓄積回数が最も多いキャラクタを選択し（ステップＶ２６）、選択されたキャラクタをオールスターチームの構成キャラクタとして登録する（ステップＶ２７）。
【００８１】
図１１のように、ＩＤに関連づけて記憶した日付を用いて古い蓄積データの削除処理を行うことで、データの蓄積に必要な記憶容量を節約できるようになり、蓄積データの記憶領域が無制限に増加してしまう事態を防止できるようになる。
【００８２】
（４）第４の処理例
図１３に本実施形態の第４の処理例についてのフローチャートを示す。図１３では、蓄積データを所与の期間毎に集計するようにしている。
【００８３】
ゲームが終了し、そのゲームのＭＶＰのキャラクタが決定されると、図１４（Ａ）に示すように、ＭＶＰキャラクタのＩＤとＩＤを蓄積した日付を、当月分のＩＤ記憶領域に記憶する（ステップＶ３１、Ｖ３２、Ｖ３３）。そして、現在の日付を確認し、月の変わり目か否かを判断する（ステップＶ３４、Ｖ３５）。そして、図１４（Ｂ）に示すように、月の変わり目（５月３１日）であった場合には、前月分の蓄積データを削除して、当月分の蓄積データに入れ替える（ステップＶ３６）。
【００８４】
次に、前月分の蓄積データを集計し、ＩＤの蓄積回数が最も多いキャラクタを選択し（ステップＶ３７）、選択されたキャラクタをオールスターチームの構成キャラクタとして登録する（ステップＶ３８）。
【００８５】
図１３のように、蓄積データを所与の期間毎に集計することで、データの蓄積に必要な記憶容量を節約できるようになり、蓄積データの記憶領域が無制限に増加してしまう事態を防止できる。また、所与の期間毎（例えば１月毎）に、オールスターチームの構成キャラクタの入れ替え処理が行われるようになるため、オールスターチームの構成キャラクタがマンネリ化する等の事態を防止できる。また、オールスターチームの構成キャラクタが月の変わり目においてどのように入れ替わったかを見たいがためにプレーヤはアミューズメント施設に出向くようになり、アミューズメント施設にプレーヤを呼び寄せる効果的な動機づけを提供できるようになる。
【００８６】
（５）第５の処理例
図１５に本実施形態の第５の処理例についてのフローチャートを示す。図１５では、１ゲーム（試合）単位で獲得されるＭＶＰポイントではなくて、過去から現在まで蓄積された各キャラクタの活躍ポイントに基づいて、オールスターチームの構成キャラクタの入れ替え処理を行っている。
【００８７】
ゲームが終了すると、ゲームに参加した全てのキャラクタについて、各々の活躍度に応じた活躍ポイントが算出される（ステップＶ４１、Ｖ４２）。一例としては、安打や盗塁の場合は１ポイント、ホームランの場合は２ポイント、勝利打点の場合は３ポイント、サヨナラ打の場合は４ポイント、サヨナラホームランの場合は５ポイント、完投の場合は２ポイント、勝利投手や救援成功の場合は３ポイント、完封の場合は５ポイント、ノーヒットノーランの場合は１０ポイントとなる。
【００８８】
次に、算出された活躍ポイントを、各キャラクタの過去の活躍ポイントに加算する（ステップＶ４３）。例えば、今回のゲームの前までのキャラクタＴ８の活躍ポイントが１００ポイントで、今回のゲームの活躍ポイントが５ポイントならば、加算後の活躍ポイントは１０５ポイントになる。キャラクタＴ８以外のキャラクタ（今回のゲームに参加したキャラクタ）の活躍ポイントについても、同様の加算処理が行われる
次に、蓄積された活躍ポイントを集計し、活躍ポイントが最も高いキャラクタを選択し、選択されたキャラクタをオールスターチームの構成キャラクタとして登録する（ステップＶ４４、Ｖ４５）。
【００８９】
図１５のように過去から現在まで蓄積された各キャラクタの活躍ポイントに基づいて入れ替え処理を行うことで、各ゲームにおいては際だった活躍はしないが、全てのゲームにおいて平均的に活躍しているキャラクタを、オールスターチームの構成キャラクタとして選出できるようになる。
【００９０】
４．ハードウェア構成
次に、本実施形態を実現できるハードウェアの構成の一例について図１６を用いて説明する。同図に示すシステムでは、ＣＰＵ１０００、ＲＯＭ１００２、ＲＡＭ１００４、情報記憶媒体１００６、音生成ＩＣ１００８、画像生成ＩＣ１０１０、Ｉ／Ｏポート１０１２、１０１４が、システムバス１０１６により相互にデータ送受信可能に接続されている。そして前記画像生成ＩＣ１０１０にはディスプレイ１０１８が接続され、音生成ＩＣ１００８にはスピーカ１０２０が接続され、Ｉ／Ｏポート１０１２にはコントロール装置１０２２が接続され、Ｉ／Ｏポート１０１４には通信装置１０２４が接続されている。
【００９１】
情報記憶媒体１００６は、プログラム、表示物を表現するための画像データ、音データ等が主に格納されるものである。例えば家庭用ゲームシステムではゲームプログラム等を格納する情報記憶媒体としてＤＶＤ、ゲームカセット、ＣＤＲＯＭ等が用いられる。また業務用ゲームシステムではＲＯＭ等のメモリが用いられ、この場合には情報記憶媒体１００６はＲＯＭ１００２になる。
【００９２】
コントロール装置１０２２はゲームコントローラ、操作パネル等に相当するものであり、プレーヤがゲーム進行に応じて行う判断の結果をシステム本体に入力するための装置である。
【００９３】
情報記憶媒体１００６に格納されるプログラム、ＲＯＭ１００２に格納されるシステムプログラム（システム本体の初期化情報等）、コントロール装置１０２２によって入力される信号等に従って、ＣＰＵ１０００はシステム全体の制御や各種データ処理を行う。ＲＡＭ１００４はこのＣＰＵ１０００の作業領域等として用いられる記憶手段であり、情報記憶媒体１００６やＲＯＭ１００２の所与の内容、あるいはＣＰＵ１０００の演算結果等が格納される。また本実施形態を実現するための論理的な構成を持つデータ構造は、このＲＡＭ又は情報記憶媒体上に構築されることになる。
【００９４】
更に、この種のシステムには音生成ＩＣ１００８と画像生成ＩＣ１０１０とが設けられていてゲーム音やゲーム画像の好適な出力が行えるようになっている。音生成ＩＣ１００８は情報記憶媒体１００６やＲＯＭ１００２に記憶される情報に基づいて効果音やバックグラウンド音楽等のゲーム音を生成する集積回路であり、生成されたゲーム音はスピーカ１０２０によって出力される。また、画像生成ＩＣ１０１０は、ＲＡＭ１００４、ＲＯＭ１００２、情報記憶媒体１００６等から送られる画像情報に基づいてディスプレイ１０１８に出力するための画素情報を生成する集積回路である。なおディスプレイ１０１８として、いわゆるヘッドマウントディスプレイ（ＨＭＤ）と呼ばれるものを使用することもできる。
【００９５】
また、通信装置１０２４はゲームシステム内部で利用される各種の情報を外部とやりとりするものであり、他のゲームシステムと接続されてゲームプログラムに応じた所与の情報を送受したり、通信回線を介してゲームプログラム等の情報を送受することなどに利用される。
【００９６】
そして図１〜図１５で説明した種々の処理は、プログラムやデータなどの情報を格納した情報記憶媒体１００６、この情報記憶媒体１００６からの情報等に基づいて動作するＣＰＵ１０００、画像生成ＩＣ１０１０或いは音生成ＩＣ１００８等によって実現される。なお画像生成ＩＣ１０１０、音生成ＩＣ１００８等で行われる処理は、ＣＰＵ１０００あるいは汎用のＤＳＰ等によりソフトウェア的に行ってもよい。
【００９７】
図１７（Ａ）に、本実施形態を業務用ゲームシステムに適用した場合の例を示す。プレーヤは、ディスプレイ１１００上に映し出されたゲーム画像を見ながら、レバー１１０２、ボタン１１０４等を操作してゲームを楽しむ。内蔵されるシステムボード（サーキットボード）１１０６には、ＣＰＵ、画像生成ＩＣ、音生成ＩＣ等が実装される。そして、本実施形態の処理（本発明の手段）を実行（実現）するための情報は、システムボード１１０６上の情報記憶媒体である半導体メモリ１１０８に格納される。以下、この情報を格納情報と呼ぶ。
【００９８】
図１７（Ｂ）に、本実施形態を家庭用のゲームシステムに適用した場合の例を示す。プレーヤはディスプレイ１２００に映し出されたゲーム画像を見ながら、ゲームコントローラ１２０２、１２０４を操作してゲームを楽しむ。この場合、上記格納情報は、本体システムに着脱自在な情報記憶媒体であるＤＶＤ１２０６、メモリーカード１２０８、１２０９等に格納されている。
【００９９】
図１７（Ｃ）に、ホスト装置１３００と、このホスト装置１３００と通信回線（ＬＡＮのような小規模ネットワークや、インターネットのような広域ネットワーク）１３０２を介して接続される端末１３０４-1〜１３０４-nとを含むゲームシステムに本実施形態を適用した場合の例を示す。この場合、上記格納情報は、例えばホスト装置１３００が制御可能な磁気ディスク装置、磁気テープ装置、半導体メモリ等の情報記憶媒体１３０６に格納されている。端末１３０４-1〜１３０４-nが、ＣＰＵ、画像生成ＩＣ、音処理ＩＣを有し、スタンドアロンでゲーム画像、ゲーム音を生成できるものである場合には、ホスト装置１３００からは、ゲーム画像、ゲーム音を生成するためのゲームプログラム等が端末１３０４-1〜１３０４-nに配送される。一方、スタンドアロンで生成できない場合には、ホスト装置１３００がゲーム画像、ゲーム音を生成し、これを端末１３０４-1〜１３０４-nに伝送し端末において出力することになる。
【０１００】
なお、図１７（Ｃ）の構成の場合に、本発明の処理を、ホスト装置（サーバー）と端末とで分散して処理するようにしてもよい。また、本発明を実現するための上記格納情報を、ホスト装置（サーバー）の情報記憶媒体と端末の情報記憶媒体に分散して格納するようにしてもよい。
【０１０１】
また通信回線に接続する端末は、家庭用ゲームシステムであってもよいし業務用ゲームシステムであってもよい。そして、業務用ゲームシステムを通信回線に接続する場合には、業務用ゲームシステムとの間で情報のやり取りが可能であると共に家庭用ゲームシステムとの間でも情報のやり取りが可能な携帯型情報記憶装置（メモリーカード、携帯型ゲーム機）を用いることが望ましい。
【０１０２】
なお本発明は、上記実施形態で説明したものに限らず、種々の変形実施が可能である。
【０１０３】
例えば、本発明のうち従属請求項に係る発明においては、従属先の請求項の構成要件の一部を省略する構成とすることもできる。また、本発明の１の独立請求項に係る発明の要部を、他の独立請求項に従属させることもできる。
【０１０４】
また、ゲームシステムが、図１８に示すように、ホスト装置（サーバー）２００に通信回線２０６を介して端末（家庭用ゲームシステム、業務用ゲームシステム）２１０-1〜２１０-nが接続される構成となっている場合には、以下のようにすることが望ましい。即ち、ゲームプレイにおける各キャラクタに関するデータ（キャラクタの活躍ポイント、活躍したキャラクタの識別データ又は蓄積時間データ等）を、ホスト装置２００のデータ蓄積部２０２に蓄積する。そして、ホスト装置２００のデータ集計部２０４が、データ蓄積部２０２に蓄積されたデータを集計する。そして、この集計結果に基づいて、ホスト装置２００又は各端末２１０-1〜２１０-nがチームの構成キャラクタの入れ替え処理を行うようにする。
【０１０５】
このようにすることで、より広い範囲のプレーヤのゲーム結果を、チームの構成キャラクタの入れ替え処理に反映できるようになる。即ち、各端末がデータを蓄積、集計すると、その端末でプレイしたプレーヤのゲーム結果しか入れ替え処理に反映できない。これに対して、図１８のようにホスト装置がデータを蓄積、集計すれば、例えば関東のプレーヤのゲーム結果、関西のプレーヤのゲーム結果、全国のプレーヤのゲーム結果というように、より広い範囲のプレーヤのゲーム結果を、入れ替え処理に反映できるようになる。なお、各端末で投票を行い、その投票データをホスト装置が蓄積、集計し、集計結果に基づいてチームの構成キャラクタの入れ替え処理を行うようにしてもよい。
【０１０６】
また本発明におけるキャラクタとしては、野球ゲームの選手以外にも、野球ゲーム以外のスポーツゲームに登場する選手、格闘ゲームに登場する格闘家、競争ゲームに登場する車やバイクや飛行機や船、ロボット対戦ゲームに登場するロボット等、種々のものを考えることができる。
【０１０７】
また、本実施形態では、スペシャルチームの構成キャラクタを入れ替える場合について主に説明したが、本発明はこれに限定されず、例えば、ノーマルチームの構成キャラクタを入れ替えるようにしてもよい。また、スペシャルチームもオールスターチームには限定されず、例えば、活躍度の低いキャラクタばかりを集めたチーム、珍プレイを行ったキャラクタばかりを集めたチーム、特殊な技を持つキャラクタばかりを集めたチーム、格闘ゲームの団体戦用のチーム等、種々のスペシャルチームを考えることができる。
【０１０８】
また、データを蓄積、集計する手法や、蓄積するデータの種類等も、図７〜図１５で説明したものに限定されず、種々の変形実施が可能である。
【０１０９】
また本発明は野球ゲーム以外にも種々のゲーム（野球ゲーム以外のスポーツゲーム、格闘ゲーム、競争ゲーム、ロボット対戦ゲーム、シューティングゲーム、ロールプレイングゲーム、音楽演奏ゲーム、ダンスゲーム等）に適用できる。
【０１１０】
また本発明は、業務用ゲームシステム、家庭用ゲームシステム、多数のプレーヤが参加する大型アトラクションシステム、シミュレータ、マルチメディア端末、画像生成システム、ゲーム画像を生成するシステムボード等の種々のゲームシステムに適用できる。
【図面の簡単な説明】
【図１】本実施形態のゲームシステムのブロック図の例である。
【図２】チームの選択画面の例について示す図である。
【図３】オールスターチームの構成キャラクタの入れ替え処理について説明するための図である。
【図４】キャラクタのＭＶＰの獲得について説明するための図である。
【図５】図５（Ａ）、（Ｂ）は、大阪、東京に設置されたゲームシステムにおいて入れ替えられたオールスターチームの構成キャラクタの例について説明するための図である。
【図６】図６（Ａ）、（Ｂ）は、ノーマルチームのゲームプレイにおいて１ゲームが成立したことを条件に、キャラクタにＭＶＰを獲得させる手法について説明するための図である。
【図７】本実施形態の第１の処理例について示すフローチャートである。
【図８】図８（Ａ）、（Ｂ）、（Ｃ）は、第１の処理例について説明するための図である。
【図９】本実施形態の第２の処理例について示すフローチャートである。
【図１０】図１０（Ａ）、（Ｂ）、（Ｃ）は、第２の処理例について説明するための図である。
【図１１】本実施形態の第３の処理例について示すフローチャートである。
【図１２】第３の処理例について説明するための図である。
【図１３】本実施形態の第４の処理例について示すフローチャートである。
【図１４】図１４（Ａ）、（Ｂ）は、第４の処理例について説明するための図である。
【図１５】本実施形態の第５の処理例について示すフローチャートである。
【図１６】本実施形態を実現できるハードウェアの構成の一例を示す図である。
【図１７】図１７（Ａ）、（Ｂ）、（Ｃ）は、本実施形態が適用される種々の形態のシステムの例を示す図である。
【図１８】ホスト装置がデータの蓄積、集計を行う手法について説明するための図である。
【符号の説明】
１００  処理部
１１０  ゲーム演算部
１１２  チーム選択部
１１４  ゲーム結果演算部
１１６  データ蓄積処理部
１１８  データ集計部
１２０  キャラクタ入れ替え部
１３０  操作部
１４０  記憶部
１４２  データ蓄積部
１５０  情報記憶媒体
１６０  画像生成部
１６２  表示部
１７０  音生成部
１７２  音出力部
１７４  通信部
１７６  Ｉ／Ｆ部
１８０  メモリーカード
【図１】
0003953231.tif 000002
【図２】
0003953231.tif 000003
【図３】
0003953231.tif 000004
【図４】
0003953231.tif 000005
【図５】
0003953231.tif 000006
【図６】
0003953231.tif 000007
【図７】
0003953231.tif 000008
【図８】
0003953231.tif 000009
【図９】
0003953231.tif 000010
【図１０】
0003953231.tif 000011
【図１１】
0003953231.tif 000012
【図１２】
0003953231.tif 000013
【図１３】
0003953231.tif 000014
【図１４】
0003953231.tif 000015
【図１５】
0003953231.tif 000016
【図１６】
0003953231.tif 000017
【図１７】
0003953231.tif 000018
【図１８】
0003953231.tif 000019