特許 7402904 情報処理システム、情報処理プログラム、情報処理装置、および情報処理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-12-13

(45)【発行日】2023-12-21

(54)【発明の名称】情報処理システム、情報処理プログラム、情報処理装置、および情報処理方法

(51)【国際特許分類】

   A63F 13/69 20140101AFI20231214BHJP

   A63F 13/798 20140101ALI20231214BHJP

   A63F 13/812 20140101ALI20231214BHJP

   A63F 13/52 20140101ALI20231214BHJP

【ＦＩ】

A63F13/69 520

A63F13/798

A63F13/812 B

A63F13/52

【請求項の数】 22

(21)【出願番号】P 2022012113

(22)【出願日】2022-01-28

(65)【公開番号】P2023110577

(43)【公開日】2023-08-09

【審査請求日】2022-10-27

(73)【特許権者】

【識別番号】000233778

【氏名又は名称】任天堂株式会社

(74)【代理人】

【識別番号】110001276

【氏名又は名称】弁理士法人小笠原特許事務所

(74)【代理人】

【識別番号】100130269

【弁理士】

【氏名又は名称】石原 盛規

(72)【発明者】

【氏名】池端 良仁

【審査官】宮本 昭彦

(56)【参考文献】

【文献】特開２０１６－０３０１０１（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／０３５７３９１（ＵＳ，Ａ１）

【文献】特開２００７－１５６８５３（ＪＰ，Ａ）

【文献】プロサッカークラブをつくろう！ONLINE，オンラインゲーム すごい攻略やってます。 Vol.17 ，株式会社双葉社，2007年07月28日，第17巻，第12～13、18、25頁，ISBN978-4-575-47925-6

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ａ６３Ｆ １３／００ － １３／９８

(57)【特許請求の範囲】

【請求項1】

情報処理装置のコンピュータに、
第１チームに関連付けられる第１スタジアムと、第２チームに関連付けられる第２スタジアムとをそれぞれ指定するスタジアム指定処理と、
仮想空間内において、指定された前記第１スタジアムに基づいた第１スタジアム部分と、指定された前記第２スタジアムに基づいた第２スタジアム部分とをそれぞれ含む、合体スタジアムオブジェクト内で前記第１チームと前記第２チームとを対戦させる対戦ゲーム処理と、
を実行させる、ゲームプログラム。

【請求項2】

前記コンピュータに、前記スタジアム指定処理において、ユーザの操作入力に基づいて複数のスタジアムから選択されたスタジアムを、前記第１スタジアムとして指定させる、請求項１に記載のゲームプログラム。

【請求項3】

前記コンピュータに、
前記第１スタジアムのランクを示すスタジアムランクに応じたスタジアムパーツを含むように、前記第１スタジアムに関する情報を更新させ、
前記対戦ゲーム処理において、前記スタジアムパーツを含む、前記合体スタジアムオブジェクト内で前記第１チームと前記第２チームとを対戦させる、請求項１または請求項２に記載のゲームプログラム。

【請求項4】

ユーザは、ゲーム内のクラブに所属可能であって、
前記クラブに関する情報と前記第１スタジアムに関する情報とが関連付けて記憶され、
前記コンピュータに、前記クラブのランクを示すクラブランクまたは当該クラブの対戦成績に応じて、前記スタジアムランクを更新させる、または、ユーザの操作入力に基づいて前記スタジアムランクを更新可能な状態にさせる、請求項３に記載のゲームプログラム。

【請求項5】

前記スタジアムパーツは観客席を含み、
前記コンピュータに、前記スタジアムランクの高さに応じた規模の前記観客席を、前記仮想空間内の前記第１スタジアム部分に配置させる、請求項３または請求項４に記載のゲームプログラム。

【請求項6】

前記スタジアムパーツは観客を含み、
前記コンピュータに、前記スタジアムランクの高さに応じた人数の前記観客を、前記仮想空間内の前記第１スタジアム部分に配置させる、請求項３から請求項５のいずれかに記載のゲームプログラム。

【請求項7】

前記コンピュータに、さらに、前記第１チームと前記第２チームの対戦中において、前記スタジアムランクに応じて、前記第１チームに対して有利な効果を与えさせる、請求項３から請求項６のいずれかに記載のゲームプログラム。

【請求項8】

前記有利な効果は、前記対戦ゲーム処理において、前記第１チームと前記第２チームの両方のチームが使用できるアイテムの出現であって、
前記コンピュータに、前記対戦ゲーム処理において、前記合体スタジアムオブジェクト内における前記第２チームに所属するキャラクタよりも前記第１チームに所属するキャラクタに近い位置に、前記スタジアムランクに応じた出現頻度で前記アイテムを出現させる、請求項７に記載のゲームプログラム。

【請求項9】

前記コンピュータに、さらに、
前記対戦ゲーム処理における対戦プレイの開始前に、前記第１スタジアムの一部と前記第２スタジアムの一部とを、離れた配置からお互いが近づくように移動させ、当該第１スタジアムの一部と当該第２スタジアムの一部とを合体させることで前記合体スタジアムオブジェクトを登場させるスタジアム合体演出を表示させる、請求項１から請求項８のいずれかに記載のゲームプログラム。

【請求項10】

前記合体スタジアムオブジェクトの半分のエリアは、前記第１スタジアム部分を用いた前記第１チームの陣地であり、前記合体スタジアムオブジェクトの残り半分のエリアは、前記第２スタジアム部分を用いた前記第２チームの陣地であり、前記第１チームの陣地と前記第２チームの陣地のそれぞれにゴールが配置され、
前記コンピュータに、前記第１チームのキャラクタと前記第２チームのキャラクタがそれぞれ相手方のチームの陣地に配置されたゴールに所定オブジェクトを入れる対戦スポーツゲームを実行させる、請求項１から請求項９のいずれかに記載のゲームプログラム。

【請求項11】

プロセッサを有するゲームシステムであって、
前記プロセッサは、
第１チームに関連付けられる第１スタジアムと、第２チームに関連付けられる第２スタジアムとをそれぞれ指定するスタジアム指定処理を実行し、
仮想空間内において、指定された前記第１スタジアムに基づいた第１スタジアム部分と、指定された前記第２スタジアムに基づいた第２スタジアム部分とをそれぞれ含む、合体スタジアムオブジェクト内で前記第１チームと前記第２チームとを対戦させる対戦ゲーム処理を実行する、ゲームシステム。

【請求項12】

前記プロセッサは、前記スタジアム指定処理において、ユーザの操作入力に基づいて複数のスタジアムから選択されたスタジアムを、前記第１スタジアムとして指定する、請求項１１に記載のゲームシステム。

【請求項13】

前記プロセッサは、
前記第１スタジアムのランクを示すスタジアムランクに応じたスタジアムパーツを含むように、前記第１スタジアムに関する情報を更新し、
前記対戦ゲーム処理において、前記スタジアムパーツを含む、前記合体スタジアムオブジェクト内で前記第１チームと前記第２チームとを対戦させる、請求項１１又は請求項１２に記載のゲームシステム。

【請求項14】

ユーザは、ゲーム内のクラブに所属可能であって、
前記クラブに関する情報と前記第１スタジアムに関する情報とが関連付けて記憶部に記憶され、
前記プロセッサは、前記クラブのランクを示すクラブランク又は当該クラブの対戦成績に応じて、前記スタジアムランクを更新する、または、ユーザの操作入力に基づいて前記スタジアムランクを更新可能な状態にする、請求項１３に記載のゲームシステム。

【請求項15】

前記スタジアムパーツは観客席を含み、
前記プロセッサは、前記スタジアムランクの高さに応じた規模の前記観客席を、前記仮想空間内の前記第１スタジアム部分に配置する、請求項１３又は請求項１４に記載のゲームシステム。

【請求項16】

前記スタジアムパーツは観客を含み、
前記プロセッサは、前記スタジアムランクの高さに応じた人数の前記観客を、前記仮想空間内の前記第１スタジアム部分に配置する、請求項１３から請求項１５のいずれかに記載のゲームシステム。

【請求項17】

前記プロセッサは、さらに、前記第１チームと前記第２チームの対戦中において、前記スタジアムランクに応じて、前記第１チームに対して有利な効果を与える、請求項１３から請求項１６のいずれかに記載のゲームシステム。

【請求項18】

前記有利な効果は、前記対戦ゲーム処理において、前記第１チームと前記第２チームの両方のチームが使用できるアイテムの出現であって、
前記プロセッサは、前記対戦ゲーム処理において、前記合体スタジアムオブジェクト内における前記第２チームに所属するキャラクタよりも前記第１チームに所属するキャラクタに近い位置に、前記スタジアムランクに応じた出現頻度で前記アイテムを出現させる、請求項１７に記載のゲームシステム。

【請求項19】

前記プロセッサは、さらに、
前記対戦ゲーム処理における対戦プレイの開始前に、前記第１スタジアムの一部と前記第２スタジアムの一部とを、離れた配置からお互いが近づくように移動させ、当該第１スタジアムの一部と当該第２スタジアムの一部とを合体させることで前記合体スタジアムオブジェクトを登場させるスタジアム合体演出を表示する、請求項１１から請求項１８のいずれかに記載のゲームシステム。

【請求項20】

前記合体スタジアムオブジェクトの半分のエリアは、前記第１スタジアム部分を用いた前記第１チームの陣地であり、前記合体スタジアムオブジェクトの残り半分のエリアは、前記第２スタジアム部分を用いた前記第２チームの陣地であり、前記第１チームの陣地と前記第２チームの陣地のそれぞれにゴールが配置され、
前記プロセッサは、前記第１チームのキャラクタと前記第２チームのキャラクタがそれぞれ相手方のチームの陣地に配置されたゴールに所定オブジェクトを入れる対戦スポーツゲームを実行する、請求項１１から請求項１９のいずれかに記載のゲームシステム。

【請求項21】

プロセッサを備えるゲーム装置であって、
前記プロセッサは、
第１チームに関連付けられる第１スタジアムと、第２チームに関連付けられる第２スタジアムとをそれぞれ指定するスタジアム指定処理を実行し、
仮想空間内において、指定された前記第１スタジアムに基づいた第１スタジアム部分と、指定された前記第２スタジアムに基づいた第２スタジアム部分とをそれぞれ含む、合体スタジアムオブジェクト内で前記第１チームと前記第２チームとを対戦させる対戦ゲーム処理を実行する、ゲーム装置。

【請求項22】

情報処理装置のコンピュータに実行させるゲーム処理方法であって、
前記コンピュータに、
第１チームに関連付けられる第１スタジアムと、第２チームに関連付けられる第２スタジアムとをそれぞれ指定するスタジアム指定処理と、
仮想空間内において、指定された前記第１スタジアムに基づいた第１スタジアム部分と、指定された前記第２スタジアムに基づいた第２スタジアム部分とをそれぞれ含む、合体スタジアムオブジェクト内で前記第１チームと前記第２チームとを対戦させる対戦ゲーム処理と実行させる、ゲーム処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、スタジアムを用いるゲームを実行する情報処理に関する。

【背景技術】

【0002】

従来から、ユーザが操作するチームと対戦相手のチームとで試合を行う球技等のスポーツゲームが知られている。また、このようなゲームでは、試合は、仮想的なスタジアムで行われていた（例えば特許文献１）。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１０－３５８２８号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

上記のゲームでは、試合を開始する際に、複数のスタジアムがユーザに提示され、ユーザにいずれか１つのスタジアムを選択させていた。そして、試合は、ユーザが選択したスタジアムで行われていた。

【0005】

しかし、上記のゲームでは、試合ごとに選択できるスタジアムは、１つだけであった。例えば、ユーザ同士が対戦する場合、ユーザがそれぞれ異なるスタジアムで対戦したいと考えていても、試合に際して選択できるスタジアムは１つだけであった。そのため、このような試合に用いるスタジアムに関して、改良の余地があった。

【0006】

それ故に、本開示における目的は、試合を行うに際して、対戦に参加するユーザ毎やクラブ毎にスタジアムが選択可能なゲームプログラム、ゲームシステム、ゲーム装置、ゲーム処理方法を提供することである。

【課題を解決するための手段】

【0007】

上記目的を達成するために、例えば以下のような構成例が挙げられる。

【0008】

構成例の一例は、情報処理装置のコンピュータに実行させるゲームプログラムであって、上記コンピュータに、スタジアム指定処理と、対戦ゲーム処理とを実行させる。スタジアム指定処理は、第１チームに関連付けられる第１スタジアムと、第２チームに関連付けられる第２スタジアムとをそれぞれ指定する。対戦ゲーム処理は、仮想空間内において、指定された第１スタジアムに基づいた第１スタジアム部分と、指定された第２スタジアムに基づいた第２スタジアム部分とをそれぞれ含む、合体スタジアムオブジェクト内で第１チームと第２チームとを対戦させる。

【0009】

上記構成例によれば、２つのスタジアムを合体させて、１つの合体スタジアムとして構成する。第１チームと第２チームは、それぞれのスタジアムを指定することができ、指定したそれぞれのスタジアムを合体させた合体スタジアム内で対戦ゲームを行うことができる。そして、この合体スタジアムを用いて対戦ゲームを実行させる。これにより、今までに無い新規な遊び方をユーザに提供できる。

【0010】

他の構成例として、コンピュータに、スタジアム指定処理において、ユーザの操作入力に基づいて複数のスタジアムから選択されたスタジアムを、第１スタジアムとして指定させさせてもよい。

【0011】

上記構成例によれば、合体させるスタジアムを複数の候補から選んで指定させるため、複数の組み合わせ方をユーザに提供している。これにより、様々な合体スタジアムで対戦ゲームをプレイさせることができる。

【0012】

更に他の構成例として、コンピュータに、さらに、第１スタジアムのランクを示すスタジアムランクに応じたスタジアムパーツを含むように、第１スタジアムに関する情報を更新させてもよい。そして、対戦ゲーム処理において、スタジアムパーツを含む合体スタジアムオブジェクト内で第１チームと第２チームとを対戦させてもよい。

【0013】

上記構成例によれば、スタジアムランクに応じたスタジアムパーツを用いてスタジアムをカスタマイズすることが可能となる。そして、当該カスタマイズされたスタジアムを合体スタジアムとして利用できる。これにより、合体スタジアムの外観のバリエーションを増やすことができ、様々な外観の合体スタジアムで対戦ゲームをプレイするという楽しみ方をユーザに提供できる。

【0014】

更に他の構成例として、ユーザは、ゲーム内のクラブに所属可能であってもよい。更に、当該クラブに関する情報と第１スタジアムに関する情報とが関連付けて記憶されていてもよい。そして、コンピュータに、クラブのランクを示すクラブランクまたは当該クラブの対戦成績に応じて、スタジアムランクを更新させる、または、ユーザの操作入力に基づいてスタジアムランクを更新可能な状態にさせてもよい。

【0015】

上記構成例によれば、ユーザが所属可能なクラブのランクや、当該クラブの対戦成績に応じてスタジアムのランクが上がっていく。これにより、スタジアムに成長・育成要素を持たせることができ、ゲームの興趣性を向上できる。

【0016】

更に他の構成例として、スタジアムパーツは観客席を含んでいてもよい。そして、コンピュータに、さらに、スタジアムランクの高さに応じた規模の観客席を、仮想空間内の第１スタジアム部分に配置させてもよい。

【0017】

上記構成例によれば、スタジアムランクを上げることで、観客席の規模を大きくすることができる。観客席の規模が大きくなれば、その分、観客動員数を増やすことができ、対戦プレイ時にゲームを盛り上げることもできる。そのため、スタジアムランクを上げることについてのユーザの動機付けを提供できる。

【0018】

更に他の構成例として、スタジアムパーツは観客を含んでいてもよい。そして、コンピュータに、さらに、スタジアムランクの高さに応じた人数の観客を、仮想空間内の第１スタジアム部分に配置させてもよい。

【0019】

上記構成例によれば、スタジアムランクを上げることで、観客動員数を増やすことができ、対戦プレイ時にゲームを盛り上げることもできる。そのため、スタジアムランクを上げることについてのユーザの動機付けを提供できる。

【0020】

更に他の構成例として、コンピュータに、さらに、第１チームと第２チームの対戦中において、スタジアムランクに応じて、第１チームに対して有利な効果を与えさせてもよい。

【0021】

上記構成例によれば、第１チームに係るスタジアムのランクに応じた効果を第１チームに対して発生させることができる。つまり、スタジアムランクを上げることで、ユーザは試合を有利に進めやすくなる。これにより、スタジアムランクを上げることへの動機付けをユーザに提供できる。

【0022】

更に他の構成例として、上記有利な効果は、対戦ゲーム処理において、第１チームと第２チームの両方のチームが使用できるアイテムの出現であってもよい。そして、コンピュータに、対戦ゲーム処理において、合体スタジアムオブジェクト内における、第２チームに所属するキャラクタよりも第１チームに所属するキャラクタに近い位置に、スタジアムランクに応じた出現頻度で上記アイテムを出現させてもよい。

【0023】

上記構成例によれば、スタジアムランクを上げることで、有利な効果を発生できるアイテムの出現頻度を高めることができる。更に、当該アイテムの出現位置について、（ユーザの操作対象となる）第１チームのキャラクタが当該アイテムを対戦相手よりも取得しやすい位置に出現させることができる。そのため、スタジアムランクを上げることで、より有利にゲームを進めることができる。これにより、スタジアムランクを上げることへの動機付けをユーザに提供できる。

【0024】

更に他の構成例として、コンピュータに、さらに、対戦ゲーム処理における対戦プレイの開始前に、第１スタジアムの一部と第２スタジアムの一部とを、離れた配置からお互いが近づくように移動させ、当該第１スタジアムの一部と当該第２スタジアムの一部とを合体させることで合体スタジアムオブジェクトを登場させるスタジアム合体演出を表示させてもよい。

【0025】

上記構成例によれば、対戦プレイ（試合）の開始前に、お互いのチームに係るスタジアムの外観を確認することができる。

【0026】

更に他の構成例として、合体スタジアムオブジェクトの半分のエリアは、第１スタジアム部分を用いた第１チームの陣地であり、合体スタジアムオブジェクトの残り半分のエリアは、第２スタジアム部分を用いた第２チームの陣地であり、第１チームの陣地と第２チームの陣地のそれぞれにゴールが配置されていてもよい。そして、コンピュータに、第１チームのキャラクタと第２チームのキャラクタがそれぞれ相手方のチームの陣地に配置されたゴールに所定オブジェクトを入れる対戦スポーツゲームを実行させてもよい。

【0027】

上記構成例によれば、相手方のゴールにボールを入れる対戦スポーツゲームにおいて、各チームに係るユーザが選択したスタジアムを自陣とすることができる。

【発明の効果】

【0028】

本開示によれば、合体スタジアムを用いた対戦ゲームという、新規な遊び方をユーザに提供できる。

【図面の簡単な説明】

【0029】

【図1】ゲーム装置２の内部構成の一例を示すブロック図

【図2】サーバの内部構成の一例を示すブロック図

【図3】スタジアム合体演出の一例を説明するための図

【図4】スタジアム合体演出の一例を説明するための図

【図5】スタジアム合体演出の一例を説明するための図

【図6】サーバの記憶部７３に記憶される各種データの一例を示すメモリマップ

【図7】ユーザデータベース２０４のデータ構成の一例

【図8】仮想クラブデータベース２０５のデータ構成の一例

【図9】記憶部２２に記憶される各種データの一例を示すメモリマップ

【図10】本実施形態のゲーム処理の詳細を示すフローチャート

【図11】試合準備処理の詳細を示すフローチャート

【図12】試合制御処理の詳細を示すフローチャート

【図13】アイテム投入制御処理の詳細を示すフローチャート

【図14】試合終了処理の詳細を示すフローチャート

【発明を実施するための形態】

【0030】

以下、一実施形態について説明する。

【0031】

［情報処理装置のハードウェア構成］
まず、本実施形態にかかる情報処理を実行するための情報処理装置について説明する。当該情報処理装置は、例えばスマートフォン、据置型または携帯型のゲーム装置、タブレット端末、携帯電話、パーソナルコンピュータ、ウェアラブル端末等である。また、本実施形態にかかる情報処理は、上記のようなゲーム装置等と、所定のサーバとから構成されるゲームシステムにも適用可能である。本実施形態では、据置型ゲーム装置（以下、単にゲーム装置と呼ぶ）を情報処理装置の一例として説明する。

【0032】

図１は、本実施形態に係るゲーム装置２の内部構成の一例を示すブロック図である。ゲーム装置２は、プロセッサ２１を備える。プロセッサ２１は、ゲーム装置２において実行される各種の情報処理を実行する情報処理部であって、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のみから構成されてもよいし、ＣＰＵ機能、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）機能等の複数の機能を含むＳｏＣ（Ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ）から構成されてもよい。プロセッサ２１は、記憶部２２に記憶される情報処理プログラム（例えば、ゲームプログラム）を実行することによって、各種の情報処理を実行する。なお、記憶部２２は、例えば、フラッシュメモリやＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の内部記憶媒体であってもよいし、図示しないスロットに装着される外部記憶媒体等を利用する構成でもよい。

【0033】

また、ゲーム装置２は、ゲーム装置２が他のゲーム装置２や所定のサーバ装置と無線通信を行うための無線通信部２３を備える。当該無線通信としては、例えば、インターネット通信や近距離無線通信が用いられる。

【0034】

また、ゲーム装置２は、ゲーム装置２がコントローラ４と有線または無線通信を行うためのコントローラ通信部２４を備える。

【0035】

また、ゲーム装置２には、画像音声出力部２５を介して表示部５（例えば、テレビ等）が接続される。プロセッサ２１は、（例えば、上記の情報処理の実行によって）生成した画像や音声を、画像音声出力部２５を介して表示部５に出力する。

【0036】

次に、コントローラ４について説明する。本実施形態のコントローラ４は、有線または無線通信によってゲーム装置２と接続可能なコントローラである。

【0037】

コントローラ４は、方向入力デバイスの一例であるアナログスティック４２を少なくとも１つ備える。当該アナログスティック４２は、方向を入力することが可能な方向入力部として用いることができる。ユーザは、アナログスティック４２を傾倒することによって傾倒方向に応じた方向の入力（および、傾倒した角度に応じた大きさの入力）が可能である。また、コントローラ４は、各種操作ボタンを含むボタン部４３を備える。

【0038】

また、コントローラ４は、慣性センサー４４を備える。具体的には、コントローラ４は、慣性センサー４４として、加速度センサー、角速度センサーを備えている。本実施形態においては、加速度センサーは、所定の３軸方向に沿った加速度の大きさを検出する。また、角速度センサーは、所定の３軸回りの角速度を検出する。

【0039】

また、コントローラ４は、上記コントローラ通信部２４と有線または無線通信を行うための通信部４１も備える。上記アナログスティック４２に対する方向入力内容、ボタン部４３の押下状態を示す情報、および、慣性センサー４４による各種の検出結果は、適宜のタイミングで繰り返し通信部４１へ出力され、ゲーム装置２に送信される。

【0040】

［サーバの構成］
次に、ゲーム装置２と通信可能な上記所定のサーバの構成について説明する。図２は、当該サーバの機能ブロック図である。サーバは、プロセッサ７２と、記憶部７３と、通信部７４とを少なくとも備えている。プロセッサ７２は、サーバを制御するための各種プログラムを実行する。記憶部７３には、プロセッサ７２によって実行される各種プログラムおよび利用される各種データが格納される。通信部７４は、有線、または無線通信によってネットワークと接続し、上記ゲーム装置２または他のサーバ（図示せず）との間で所定のデータを送受信する。

【0041】

ここで、本実施形態では、ユーザが以下に説明するゲームを開始する際は、当該ユーザが使用するゲーム装置２が当該所定のサーバに接続され、ログイン処理が行われる。ログインができれば、ゲーム処理に必要となる各種のデータが当該サーバから当該ゲーム装置２に送信される。ゲーム装置２では、受信したデータを記憶し、このデータに基づいて以下に説明するようなゲーム処理が実行される。

【0042】

［本実施形態で想定するゲームについて］
次に、本実施形態にかかるゲーム装置２で実行されるゲーム処理（情報処理の一例）の概要を説明する。まず、本実施形態で想定するゲームは、球技をモチーフにしたスポーツゲームである。本実施形態では、球技の一例として、自陣と敵陣のそれぞれにゴール（に相当するもの）が存在しており、当該ゴールにボール（またはボールに相当する物）を入れることで得点可能な球技のスポーツゲームを想定して説明する。例えば、サッカーやバスケットボール、ホッケー等のような球技等をモチーフにしたスポーツゲームである。また、格闘技（剣道や柔道、ボクシング等）の個人戦や団体戦をモチーフにしたスポーツゲームでもよい。以下の説明では、一例として、サッカーをモチーフにしたスポーツゲームを想定して説明する。

【0043】

本ゲームでは、仮想的な人型のオブジェクトである、複数の選手キャラクタオブジェクト（以下、単に選手キャラクタと呼ぶ）を、第１のチームと第２のチーム（味方チームと敵チーム）とに分けている。各チームの選手キャラクタは、仮想空間内に用意されたスタジアムオブジェクト（後述）に含まれる選手配置領域（以下、フィールドと呼ぶ）内に配置される。当該フィールドは、選手キャラクタによって試合が行われる領域である。本実施形態では、説明をわかりやすくするため、このフィールドの具体的なイメージとして、サッカーにおけるフィールドをモチーフにしたものを一例として説明する。

【0044】

本実施形態では、各チームは、５人の選手キャラクタで構成される。その内訳は、１人がゴールキーパー（以下、ＧＫ）であり、残り４人がフィールドプレイヤーである。ここで、本ゲームでは、ユーザの操作対象となり得るのは４人のフィールドプレイヤーであり、ＧＫに関しては、試合中は終始、ＡＩによる自動制御が行われるものとする。

【0045】

また、本ゲームでは、上記のようなフィールドを少なくとも含む「スタジアム」で試合が行われる。ユーザは、試合開始前に、試合で使用するスタジアムを選択することが可能である。この選択可能なスタジアムの種類について、本ゲームでは、ゲームにおいて最初から用意されている「既定スタジアム」の他に、ユーザがカスタマイズ可能なスタジアムであるホームスタジアム（詳細は後述）を選択することも可能となっている。

【0046】

また、本ゲームは、マルチプレイも可能となっている。本実施形態では、複数のゲーム装置２が、インターネットおよび上記所定のサーバを介して接続され、ネットワーク経由でマルチプレイが可能なものを想定する。なお、他の実施形態では、複数のゲーム装置２がピアツーピア方式で、インターネットを介さずに直接的に接続される態様で、マルチプレイが可能なものであってもよい。

【0047】

ここで、本実施形態では、マルチプレイの参加人数が２人の場合を例に説明する。すなわち、１チームを１人のユーザが担当する態様で対戦プレイする場合を例示する。各ユーザは、自分の担当するチームの４体のフィールドプレイヤーについて、試合中に操作対象を切り替えながらゲームを進行する（同時に操作できるのは１体のみで、操作対象ではないフィールドプレイヤーはＡＩ制御となる）。

【0048】

なお、他の実施形態では、上記フィールドプレイヤー１体の操作を１人のユーザが担当する態様で、最大８人まで参加可能なものとしてもよい。この場合、１ユーザに１台のゲーム装置が割り当てられ、最大で８台のゲーム装置２がネットワーク経由で接続される態様となる。

【0049】

また、本ゲームでは、ユーザ同士の対戦プレイの他、”ユーザ ＶＳ ＣＰＵ”、”ＣＰＵ” ＶＳ ＣＰＵ”という対戦プレイも可能である（後者の場合は、ユーザはＣＰＵ同士の対戦を観戦することになる）。

【0050】

［仮想的なクラブについて］
ところで、例えば現実のサッカーにおいては、「サッカークラブ」のような団体が存在している。本ゲームでは、このような団体をゲーム上に仮想的に再現して、ユーザ同士のコミュニティを楽しめるよう構成されている。具体的には、ユーザは、仮想的なクラブ（以下、単に仮想クラブと呼ぶ）を作成することができる。あるいは、ユーザは、他のユーザが作成した仮想クラブに加入（所属）することが可能である。なお、以下の説明では、仮想クラブを作成したユーザのことを「オーナー」と呼ぶ。なお、オーナーとしての役割・権限については、他のユーザに譲渡することも可能である。

【0051】

また、上記のような対戦プレイにおいては、各チームの選手キャラクタは同じクラブに属している選手であるとする。つまり、上記の試合は、仮想クラブＶＳ仮想クラブ、という態様の対戦にもなる。

【0052】

［ホームスタジアムについて］
また、例えば現実の野球やサッカーにおいては、球団やサッカークラブは、「ホーム」となる球場やスタジアムを有することが多い。この要素をゲーム内で再現すべく、本ゲームでは、上記仮想クラブ毎に、１つのホームスタジアムオブジェクト（以下、単にホームスタジアムと呼ぶ）を割り当てている。更に、当該ホームスタジアムは、その外観等をカスタマイズすることが可能となっている。カスタマイズ可能な要素は、例えば、上記フィールドに配置可能なフェンスやゴール等の各種オブジェクトのデザイン、後述する観客席オブジェクト等である。以下では、当該カスタマイズ可能な要素のことを「スタジアムパーツ」と呼ぶ。また、本ゲームでは、ホームスタジアムの周囲（例えば円形の所定範囲）の地形等・外観についてもカスタマイズすることができる。そして、ホームスタジアムの全体的な外観、およびホームスタジアムの周囲に配置される地形オブジェクトについては、「テーマ」というスタジアムパーツとしてカスタマイズ可能である。例えば、「森林」というテーマの場合は、スタジアムの全体的な外観が、緑色を基調としたデザインとなり、大樹の切り株をくりぬいた中にフィールドがあるようなスタジアムとなる。また、ホームスタジアム周辺の地形も、樹木が多数存在するような地形となる。また、例えば「都市」というテーマの場合、スタジアムの全体的な外観は、コンクリート製のスタジアムの外観となり、周辺の地形についても、ビルや道路が存在するような、都市的な見た目の地形となる。また、テーマが「海辺」であれば、例えば外壁がなく、観客席が砂浜であるような開放的なスタジアムの外観となり、周辺の地形についても、スタジアムが海に囲まれているような見た目の地形となる。以下の説明では、「スタジアム（ホームスタジアム、および上記既定スタジアム）」と呼ぶときは、この周囲の地形も含めたものとして扱うが、他の実施形態では、周囲の地形部分は含めずに、建造物であるスタジアム部分だけをスタジアムとして扱ってもよい。

【0053】

なお、各スタジアムのフィールドについて、フィールドのサイズそのものについては、全スタジアムで共通のサイズであるものとする。また、本実施形態では、スタジアム全体の底面部分のサイズについても、全スタジアムで共通のサイズであるとする。但し、他の実施形態では、フィールドのサイズは共通ではあるが、スタジアム全体の底面については、必ずしも共通サイズでなくてもよい。例えば、俯瞰した場合に、スタジアム周辺の地形を含めて円形の範囲を有するスタジアムを想定した場合、この円形の範囲の半径自体はスタジアムによって異なる半径であってもよい。なお、本実施形態では、どのような形状のスタジアムであっても、そのスタジアムの中心位置が、上記フィールドの中心位置と一致するような構成であるとする。

【0054】

ここで、ホームスタジアムのカスタマイズ操作（手法）に関して説明する。本ゲームでは、上記オーナーは、所定額のゲーム内通貨を消費することで、上記スタジアムパーツを「購入」できる。当該ゲーム内通貨の入手方法は、試合を行うことであり、試合結果（勝敗）に応じた所定額が得られる。そして、当該ゲーム内通貨を消費することで、例えば、異なるデザインのフェンスやゴールを「購入」できる。オーナーは、所定のカスタマイズ用画面において、購入済みのスタジアムパーツを選択し、ホームスタジアムに適用する操作を行うことができる。これにより、ホームスタジアムのスタジアムパーツを変更等することができる。

【0055】

なお、本ゲームでは、ホームスタジアムをカスタマイズする権限は上記オーナーにのみ与えられているものとするが、他の実施形態では、権限譲渡等の処理によって、オーナー以外のユーザもカスタマイズの権限を有するようにしてもよい。

【0056】

［ホームスタジアムの観客要素について］
また、本ゲームでは、ホームスタジアムは「観客」の要素も有している。具体的には、ホームスタジアムには「観客配置領域」が含まれている。試合が行われる際、当該観客配置領域には所定数の観客オブジェクト（以下、単に観客と呼ぶ）が配置される。当該観客は、試合中、所定の時間間隔で、「アイテムボックス」というオブジェクトをフィールドに投げ入れる（投入する）。当該所定の時間間隔については詳細を後述するが、観客数が多いほど、当該投入する時間間隔が短くなり、１試合におけるアイテム投入回数が増加し得る。なお、本ゲームでは、あるホームスタジアムに配置される観客は、当該ホームスタジアムに対応する仮想クラブ（以下、応援クラブ）を応援している、という体裁となっている。換言すれば、あるホームスタジアムに配置される観客は全員、当該ホームスタジアムを有する仮想クラブのサポーターであるという設定である。

【0057】

本実施形態では、上記アイテムボックスは、箱のような外観を有するオブジェクトであり、一見しただけでは具体的なアイテム内容がわからないものとなっている。そして、フィールドプレイヤーが当該アイテムボックスに接触すると、抽選で選択されたアイテムがその場に出現し、当該フィールドプレイヤーは当該出現したアイテムを自動的に取得することができる。当該所定のアイテムは、ゲーム進行に有利な何らかの効果を付与するものである。なお、本実施形態では、当該アイテムの効果を発生させるために、所定のアイテム使用操作を要求するものとする。ユーザは、当該アイテムの取得後、所定のタイミングでアイテム使用操作を行うことで、当該アイテムに係る効果を発生させることできる。この点、他の実施形態では、取得と同時に効果が発生するようなアイテムを出現させてもよい。

【0058】

ここで、上記のようなアイテムの効果について、例をいくつか示す。まず、当該アイテムとして、選手キャラクタの性能を高める効果（性能向上機能）を有するアイテムがある。例えば、そのアイテムを取得した選手キャラクタの移動速度を一時的に高める効果を有するアイテム等である。また、選手キャラクタの動作・行動を阻害するような効果（妨害機能）を有するアイテムもある。例えば、投げつけると当たった相手を吹き飛ばすことができるアイテムや、爆弾のようなアイテムであって、爆発させることで所定範囲の選手キャラクタを一時的に移動停止させるようなアイテムである。

【0059】

また、本ゲームでは、上記のアイテムは、共用アイテムと専用アイテムとの２種類のアイテムに分類される。共用アイテムは、対戦している２チームのいずれの選手キャラクタも取得・利用可能なアイテムである。専用アイテムは、そのアイテムを投入した観客が属するホームスタジアムの仮想クラブの選手キャラクタのみが取得・利用可能なアイテムである。つまり、観客から見て、上記応援クラブの選手キャラクタのみが使えるアイテムである。本ゲームでは、上記のような効果を有する各種のアイテムが共用アイテムと専用アイテムとに分けて記憶されており、これらのうちのいずれかのアイテムが抽選によって、アイテムボックスとして投入されるアイテムとして抽選される。

【0060】

更に、本ゲームでは、観客がアイテムボックスを投入する位置について、次のような制御も行う。すなわち、アイテムボックスを投入する位置（目標地点）として、応援クラブの選手キャラクタの位置、あるいはその近傍の位置を設定している。つまり、対戦チームのフィールドプレイヤーよりも、応援クラブのフィールドプレイヤーが取得しやすいような位置にアイテムボックスを投入するような制御も行っている。上記のような共用アイテムの場合は、味方チームも敵チームも取得可能であるところ、このように投入位置を調整することで、そのホームスタジアムに係る仮想クラブにとって、有利な効果をより発生させやすくしている。

【0061】

なお、本実施形態では、アイテムの取得に関して、アイテムボックスへの接触と同時に上記アイテムを取得する場合を例示する。この場合、他の選手キャラクタにアイテムを取られる可能性はないといえる。この点、他の実施形態では、アイテムボックスへの接触と、出現したアイテムへの接触とを個別に判定するようにしてもよい。この場合は、例えば選手キャラクタＡがアイテムを出現させ、選手キャラクタＢが当該出現したアイテムを取得することも可能である。また、更に他の実施形態では、上記のようなアイテムボックスは用いずに、直接的にアイテムを投入するようにしてもよい。

【0062】

また、アイテムボックスから出現するアイテムについては、例えばアイテムボックスの投入に際して抽選で選ばれるが、本実施形態では、その時点で不利なチームのほうがより効果の高いアイテムが当選されやすくなるように、当選率の調整も行う。

【0063】

［ホームスタジアムの成長要素について］
次に、ホームスタジアムの成長要素に関して説明する。本ゲームでは、上記ホームスタジアムに、「スタジアムランク」という成長要素を付加している。本ゲームでは、当該スタジアムランクは、４段階（ランク１～ランク４）まであり、最初はスタジアムランク１から始まり、スタジアムランクが上がることで、ホームスタジアムの規模が大きくなっていく。上記のように、ホームスタジアムは仮想クラブに対応づけられて割り当てられるものであるため、スタジアムランクは、仮想クラブの成長度合いを示す情報という側面も有する。

【0064】

上記スタジアムランクの上げ方について説明する。まず、前提として、仮想クラブの作成直後は、スタジアムランクは１であり、２～４は「ロック」された状態であるとする。そして、所定の条件を満たすことで、現在のランクの一つ上のランク（上位ランク）を「アンロック」できる。アンロックのための条件として、本実施形態では、以下の２つの条件のいずれかを満たすことを要求する。１つめの条件は、試合の勝利数が所定数に達することである。ゲーム内では、勝利数が所定数に達するとリーグ昇格となり、この昇格に伴って、上位ランクがアンロックされるという処理が行われる（なお、リーグが降格しても、アンロック状況に変化はないものとする）。２つめの条件は、勝敗関係無く、累計試合数がランク毎に定められている所定の数に到達することである。本実施形態では、これら２つの条件のいずれかを満たせば、上位ランクが「アンロック」される。なお、これらの条件は一例であり、他の条件や他の方法を用いてスタジアムランクを上げるように構成してもよい。

【0065】

上記のような条件を満たすことで上位ランクがアンロックできれば、アンロックされたランクに応じた上記スタジアムパーツが購入可能な状態となる。本ゲームでは、上述したようなスタジアムパーツについて、購入可能なスタジアムパーツをランク毎に分けている。例えば、同じ「フェンス」のパーツであっても、スタジアムランク１で購入できる「フェンスＡ」と、スタジアムランク２にならないと購入できない「フェンスＢ」が存在している。また、例えば、スタジアムランク１～２では購入できないが、スタジアムランクが３になると購入可能になるスタジアムパーツもある。その他、スタジアムランクに応じた各種のスタジアムパーツが用意されている。

【0066】

ここで、上記購入可能なスタジアムパーツの一つとして、「観客席オブジェクト」（以下、単に観客席と呼ぶ）というものがある。当該観客席は、上記観客配置領域に配置可能なオブジェクトであり、上記観客は、この観客席の上に配置される。例えば、配置された観客席に座るような態様で観客が配置される（換言すれば、観客自体が実質的にスタジアムパーツの一種であるともいえる）。そして、当該観客席についても、上記スタジアムランクに応じた観客席が用意されている。本ゲームでは、より高いスタジアムランクに応じた観客席のほうが、下位のものよりも、その席数や規模が大きいものとなっている。

【0067】

スタジアムランクに応じた規模の変化の一例を示す。例えば、スタジアムランク１では、ホームスタジアムの見た目は、フィールドはフェンス等の無いグラウンドのようなもので、全体として「練習場」のような見た目である。また、この段階で購入・配置可能な観客席は、芝生のような見た目のオブジェクトとなる（つまり、椅子形状の観客席ではなく、地面に直接座るような芝生型の観客席である）。また、その席数としては例えば１００席分である。次に、スタジアムランク２に上がると、ホームスタジアムの見た目については、フィールドにフェンス等が設置可能となり、小規模スタジアム程度の見た目に変化し得る。また、購入・配置可能な観客席は、椅子型あるいはベンチ型の観客席となる。また、この観客席は１階席の分だけの観客席であり、席数は例えば３００席分である。次に、スタジアムランク３になると、ホームスタジアムの見た目については、例えば照明等も配置可能な、中規模のスタジアム程度の見た目に変化し得る。購入・配置可能な観客席については、２階席まである観客席となり、席数は例えば６００席分となる。更に、スタジアムランク４になると、ホームスタジアムの見た目は、大型スクリーン等も配置可能な大規模スタジアムの見た目に変化し得る。購入・配置可能な観客席については、３階席まである屋根付きの観客席となり、その席数も、例えば１０００席分となる。このように、スタジアムランクが上がるに連れて、観客席の規模も大きくなっていくため、そこに配置される観客の上限数も上がっていくことになる。例えば、ランク１では１００人、ランク２では３００人、ランク３では６００人、ランク４では１０００人、というように配置可能な観客の上限数が上がっていく（上述したように、観客が多いほうが、上記アイテムボックスが投入される機会も増えることになる）。

【0068】

なお、観客席の購入に際して、本実施形態では、１度の購入で、スタジアムランクに応じた最大席数分の観客席（例えば、ランク１の場合は１００席分）を購入でき、１度の配置操作で１００席分をまとめて配置できるものとする。他の実施形態では、１席ずつ（または任意の席数分で）観客席を購入および配置可能としてもよい。

【0069】

また、本実施形態では、観客オブジェクト自体について、複数の種類が用意されている。そして、スタジアムランクに応じて、配置される観客の種類数が増えていく。例えば、見た目が異なる観客Ａ～観客Ｄの４種類の観客オブジェクトがあるとする。そして、スタジアムランク１では、観客Ａしか配置されないが、スタジアムランク２では、観客ＡおよびＢが配置されるようにしている。更に、スタジアムランク３では、観客Ａ、観客Ｂ、観客Ｃの３種類が、スタジアムランク４では、観客Ａ～観客Ｄの４種類が配置されるようにしている。

【0070】

ここで、本実施形態では、試合の際に配置される観客数については、常に満席状態となる数であるとする（観客席数＝観客数）。上記のように、観客席の規模はスタジアムランクと連動するような関係である。そのため、スタジアムランクを上げることで、観客数が増加し、スタジアムランクに応じた（上記投入されるアイテムによる）有利な効果を得る機会を増やすことができる。また、本実施形態では、スタジアムランクが４段階ある例を挙げているため、観客数も、スタジアムランクに応じて１段階～４段階まで、段階的に増加していくことになる。

【0071】

なお、他の実施形態では、試合時の観客数と観客席数とに差異があってもよい（つまり、空席があってもよい）。例えば、スタジアムランク１の場合は、観客数を１～１００人の範囲内の所定の人数とし、スタジアムランク２の場合は、１～３００人の範囲、あるいは、１０１～３００人の範囲内の所定の人数、というように決定してもよい。またこの際、人数の決定手法は、ランダムでもよいし、例えば、仮想クラブ毎に「人気度」というパラメータ（例えば試合の勝敗に応じて増減する）を設けておき、この人気度に基づいて決定するようにしてもよい。

【0072】

また、本実施形態では、観客と観客席を異なるオブジェクトとして扱うが、他の実施形態では、観客席オブジェクトは用いずに、観客だけを観客配置領域に配置するようにしてもよい。この場合、観客の数については、スタジアムランクに高さに応じた人数を配置するようにすればよい。

【0073】

また、更に他の実施形態では、「１つの観客席」と「観客（少なくとも１人）」を１セットにしたオブジェクトを「観客席」（または「観客」）として扱うようにしてもよい。

【0074】

次に、上記観客が上記アイテムボックスを投入する時間間隔（投入頻度）に関して説明する。本実施形態では、観客は、試合中、所定の時間間隔でアイテムボックスを投入する。この時間間隔は、上記スタジアムランクによって異なっている。例えば、スタジアムランク１の場合、（試合開始時から）１２０秒間隔でアイテムが投入される。これがスタジアムランク２になると、例えば９０秒間隔でアイテムが投入され、スタジアムランク３になると、例えば６０秒間隔でアイテムが投入され、スタジアムランク４になると、例えば３０秒間隔でアイテムが投入される。また、この投入タイミングの決定に際しては、所定の期間からランダムで選択されたタイミングとしてもよい。例えば、上記１２０秒間隔とする代わりに、１１０秒～１３０秒の期間からランダムに選ばれたタイミングを、上記投入のタイミングとしてもよい。そして、次回の投入タイミングについて、今回の投入タイミングから１１０秒～１３０秒後の期間からランダムで選ばれたタイミングとしてもよい。このように、スタジアムランクに応じてアイテムボックスの投入間隔を短縮していくことで、スタジアムランクを上げるに連れて、有利な効果をより発生しやすくすることができ、ユーザがスタジアムランクを上げることへの動機付けを提供できる。

【0075】

更に、本ゲームでは、試合に対する観客の熱中度を示すパラメータ（以下、単に熱中度と呼ぶ）を用いる。そして、当該熱中度の上昇に応じて、上記アイテムボックスの投入間隔を更に短縮するという制御も行う。以下、一例を説明する。まず、上記のようなスタジアムランクに応じた投入間隔のことを、初期投入間隔と呼ぶ。また、熱中度については、試合開始時の初期値が“０”であるとする。そして、試合中、熱中度を上げるための所定の条件（以下、熱中度上昇条件）が満たされる度に、当該熱中度が上がっていく。当該熱中度上昇条件は、例えば、シュートを決めた場合等、観客を沸き立たせるようなプレイとして予め設定されているプレイが行われることである。また、このような熱中度上昇条件が満たされたときに上昇する値についても、スタジアムランクに応じて異なる。本ゲームでは、スタジアムランクが高いほど、上昇する値はより大きくなる。例えば、シュートを決めた場合、熱中度の上昇値は、スタジアムランク１では“１“、スタジアムランク２では、”２“、スタジアムランク３では、”４“、スタジアムランク４では、”８“としてもよい。そして、熱中度が予め決められた閾値を越える毎に、アイテムの投入間隔が短縮される。例えば、熱中度が２０を越えれば、上記アイテムの投入間隔を初期投入間隔から１０秒短縮し、その後、熱中度が５０を越えれば、更に１０秒短縮する、等の制御が行われる。

【0076】

更に、上記熱中度の上昇値については、上記スタジアムランクによる違いに加えて、熱中度上昇条件を満たすものとして定義されているプレイ毎に異なる上昇値が設定されていてもよい。

【0077】

なお、本実施形態では、熱中度上昇条件として所定のプレイが行われることを挙げたが、この他、例えば、ハットトリックを決める等、試合に関する所定の条件が満たされた場合にも、熱中度を上昇させてもよい。

【0078】

［スタジアム合体について］
上記のように、ホームスタジアムのスタジアムランクを上げることで、試合中に有利な効果を得られやすくなるが、これは、ユーザが、自身の所属する仮想クラブのホームスタジアムで試合を行った場合の話となる。この点、従来のゲームは、試合を開始する際に使用するスタジアムを複数の候補（上記既定スタジアム相当）の中から１つだけ選択するものであった。例えば、ユーザＡとユーザＢが対戦プレイを行いたい場合、選択肢として複数のスタジアムが一覧表示されたとしても、対戦プレイの舞台となるスタジアムについては、この中から選ばれたいずれか一つのスタジアムとなる。そのため、仮に、ユーザＡとユーザＢが異なる仮想クラブに所属しており、各クラブが成長させたホームスタジアムを有しており、両クラブのホームスタジアムが上記のようなスタジアムの一覧に表示されたとしても、いずれか１つのスタジアムを選択するしかない。この場合、選択されなかったホームスタジアムのクラブに属するユーザは、ホームスタジアムに係る上記のような有利な効果の恩恵を十分に受けることができない。

【0079】

また、上記のように、ホームスタジアムをユーザがカスタマイズ可能とすることで、ユーザ同士でカスタマイズしたホームスタジアムを見せ合いたい、というニーズが発生することも想定される。しかし、上記のように試合に際してスタジアムが１つしか選べない場合、このようなニーズに十分対応できない可能性もある。

【0080】

そこで、本実施形態では、試合を行うに際して、対戦する２人のユーザに係るホームスタジアムと、上記既定スタジアムとを含む複数のスタジアムを一覧表示し、このうちから２つのスタジアムをユーザに選択させる。例えば、ユーザは第１のスタジアムを選択し、対戦相手となるユーザは、第２のスタジアムを選択する（ここでは双方とも、自分の仮想クラブのホームスタジアムを選択したとする）。そして、選択された２つのスタジアムを合体させて１つの「合体スタジアム」を生成し、当該合体スタジアムを用いて試合を行うことを可能としている。この合体に関して、本実施形態では、各スタジアムを予め２つの部分に分割する。当該分割位置について、本実施形態では、少なくとも上記フィールドを等分されるような位置で分割する。本実施形態では一例としてサッカーのフィールドを想定し、当該フィールドの、いわゆるセンターラインに沿って分割する。つまり、２分割した各スタジアム部分の一方には、フィールドの自陣部分が含まれ、他方には、敵陣部分が含まれるように分割する。以下の説明では便宜上、フィールドが横長形状に見えるよう俯瞰した場合を想定し、上記のように分割した後の各部分を「右半分部分」「左半分部分」と呼ぶ。そして、本実施形態では、上記選択された２つのスタジアムの片方部分同士を合体させることで、合体スタジアムを生成する。例えば、仮想クラブＡ（第１プレイヤの操作対象）のホームスタジアムＡの左半分部分と、仮想クラブＢ（第２プレイヤの操作対象）のホームスタジアムＢの右半分部分とを合体させて、１つの合体スタジアムとする。この際、上記フィールドの中心を合わせるようにして合体させる。上記のように、フィールドサイズ自体は全スタジアムで共通のサイズであるため、少なくともフィールド部分については、どのスタジアムの組み合わせで合体させても、同じサイズのフィールドが構成されるようにする。一方、それ以外の部分（スタジアムの外壁や観客席等）については、その見た目が異なるもの同士が組み合わされることになる。

【0081】

なお、本実施形態では、フィールドの外観については共通の外観を用いるものとする。但し、他の実施形態では、フィールドの外観に関してもその他の部分と同様に異なるようにしてもよい。例えば、第１のスタジアムのフィールドの外観は緑色の芝生であり、第２のスタジアムのフィールドの外観は茶色の芝生である、というようなものであってもよい。また、更に他の実施形態では、各ホームスタジアムのフィールド部分に「属性」を持たせ、ホームスタジアム毎に異なる属性としてもよい。例えば、属性として、移動のしやすさに関するパラメータを設けておき、第１のスタジアムのフィールドは「芝生」、第２のスタジアムのフィールドは「砂浜」として、砂浜のほうが芝生よりも移動速度等が低下するような構成としてもよい。

【0082】

また、ホームスタジアム同士を合体させた場合の合体スタジアムのフィールドについては、各クラブのホームスタジアムにかかるフィールド部分が、そのクラブの「自陣」となる。

【0083】

また、スタジアムの選択に関して、ここではユーザ同士が対戦する場合を例示するが、“ユーザ ＶＳ ＣＰＵ”、または“ＣＰＵ ＶＳ ＣＰＵ”という対戦の態様の場合、ＣＰＵが自身の分のスタジアムを選択するようにしてもよいし、ＣＰＵに代わってユーザがＣＰＵの分のスタジアムを選択するようにしてもよい。

【0084】

更に、本ゲームでは、試合開始前の演出として、このようなホームスタジアムが合体して１つのスタジアムとなる様子を「スタジアム合体演出」としてユーザに提示する。本実施形態では、２つのスタジアムの半分同士が、離れた位置から互いに近づくように移動して、断面部分をくっつけるようにして１つの合体スタジアムができる様子を、スタジアム合体演出として表示する。図３～図５に、このようなスタジアム合体演出の一例を示す。これらの図は、仮想空間において、スタジアムを俯瞰するような位置に仮想カメラがある場合の図として示している。例えば、図３に示すように、３次元仮想空間内で、最初は、第１のスタジアムと第２のスタジアムとの、それぞれ対向する関係になる半分部分が、お互いに離れた位置に出現する。この半分部分については、ここでは便宜上、右半分または左半分と呼ぶ。この左右関係は、フィールドが横長の姿勢で見えるように俯瞰した場合の位置関係を想定している。また、出現する際には、この半分同士の２つのスタジアムの断面部分同士が向き合うような姿勢で出現する。なお、図３の例では、図の左側に第１スタジアムの左半分、右側に第２スタジアムの右半分が出現する例を示しているが、この関係は逆の関係であってもよい。すなわち、第２スタジアムの左半分と第１スタジアムの右半分とが出現するようにしてもよい。この後、図４に示すように、お互いに近づくように移動する様子が表示される。そして、図５に示すように、断面部分同士がくっついて、１つの合体スタジアムとなる様子が表示される。この後、仮想カメラは合体スタジアムに近づいていき、更に、スタジアム内の各所を巡るようなカメラワークが行われてもよい。例えば、各スタジアムのゴールをアップで映すようなカメラワークが行われてもよい。また、これらの図では俯瞰した図で説明したが、スタジアム合体演出中に係る仮想カメラのカメラワークは任意であり、様々な位置や角度から映すようにしてもよいことは言うまでもない。

【0085】

上記のような合体演出をユーザに提示することで、対戦プレイの実行に係る一連の操作の流れにおいて、各ユーザがカスタマイズしたホームスタジアムを見せ合うという新たな楽しみ方を提供できる。すなわち、上記のようにホームスタジアムをカスタマイズ可能とすることにより、自分が作ったホームスタジアムを他のユーザに見せたい、あるいは、他ユーザが作ったホームスタジアムを見てみたい、というニーズが発生することも考えられる。本ゲームのように、試合開始前にホームスタジアムの合体演出を表示することで、対戦プレイを行う際の操作の流れに載せて、このようなニーズに対応することが可能となる。更に、各ユーザは、お互いのホームスタジアムの観客席や観客数の違いを視認することができるため、試合前に、対戦相手のスタジアムランクを把握することも可能となる。これにより、スタジアムランクの差の有無やそれに応じた試合の組み立て方等を試合前にユーザに検討させることが可能となり、ゲームの戦略性を高めて、ゲームの興趣性をより向上させることも可能となる。

【0086】

ここで、合体スタジアムにおける境界（断面）部分に関して補足説明する。例えば、スタジアムランク１とスタジアムランク４のホームスタジアムでは、スタジアム自体の形状や観客席の階数等の差があり、合体スタジアムの境界における断面部分について高低差が生じることもある。例えば、スタジアムランク４の３階建ての観客席について、合体スタジアムの境界部分ではその断面部分が見えるような状態になり得る。そのため、本ゲームでは、ホームスタジアム（の外観のデータ）については、上記のような右半分部分と左半分部分とで個別に持つようなデータ構成とし、上記断面となり得る部分については、不自然に見えないように、適切なテクスチャの貼り付けなどが行われる。

【0087】

ところで、仮想クラブのホームスタジアム同士を合体させた場合、合体スタジアムでは、観客についても、２つのクラブの観客が存在することになる。そして、本実施形態では、上記アイテム投入について、各ホームスタジアムに係る観客毎に個別に制御する。そのため、例えば、スタジアムランク１とスタジアムランク３のホームスタジアムが合体した場合、少なくとも試合開始直後の状態では、スタジアムランク３の仮想クラブに係るチームのほうがアイテム投入の頻度が高く、その分有利な状態となる。但し、試合展開と上記熱中度の上昇具合によって、アイテム投入頻度の差は埋まる可能性もある。

【0088】

なお、本実施形態では、仮想クラブのホームスタジアムが選択される場合を例に説明するが、いずれか一方、あるいは両方が既定のスタジアムの場合でも同様に、既定スタジアムの半分部分を用いて合体スタジアムが生成される。但し、既定スタジアムを用いる場合は、上記のような観客からのアイテム投入による有利な効果の恩恵を受けることはできなくなる。この点、他の実施形態では、既定スタジアムを用いる場合でも、例えばスタジアムランク１（つまり、最低ランクの場合）と同等の扱いとして、既定スタジアムに観客を配置し、上記のようなアイテム投入の制御を行わせてもよい。この場合、スタジアムの成長に基づく恩恵までは受けることはできないが、アイテム投入による有利な効果の恩恵自体は受けることが可能となる。

【0089】

上記のように、本実施形態では、ホームスタジアム（仮想クラブ）に成長要素を導入し、その成長度合いに応じて試合中に有利な効果を与えるような制御を行っている。また、２つのスタジアムを合体させた合体スタジアムで試合（対戦プレイ）を行うことも可能としている。これにより、今までにない新たな楽しみ方が可能なスポーツゲームを提供できる。

【0090】

［本実施形態のゲーム処理の詳細］
次に、図６～図１４を参照して、本実施形態におけるゲーム処理についてより詳細に説明する。まず、本ゲーム処理で利用される各種データに関して説明するが、ここでは、上記所定のサーバに記憶されるデータについて説明した後、ゲーム装置２に記憶され得るデータについて説明する。

【0091】

［サーバに記憶されるデータについて］
図６は、上記所定のサーバの記憶部７３に記憶されるプログラムおよびデータの一例を示すメモリマップである。記憶部７３には、プログラム記憶領域２０１およびデータ記憶領域２０３が含まれている。プログラム記憶領域２０１には、サーバ側ゲーム処理プログラム２０２が記憶される。また、データ記憶領域２０３には、ユーザデータベース２０４、仮想クラブデータベース２０５、その他のゲーム関連データ２０６が少なくとも格納される。

【0092】

サーバ側ゲーム処理プログラム２０２は、本実施形態に係るゲーム処理においてサーバ側が担当する各種機能（ログイン処理や、対戦相手のマッチング処理等）を当該サーバに実行させるためのプログラムである。

【0093】

ユーザデータベース２０４は、本実施形態に係るゲームの各ユーザについての情報を記憶したデータベースである。図７は、ユーザデータベース２０４のデータ構成の一例を示す図である。ユーザデータベース２０４は、複数のユーザレコード２１４で構成されている。各ユーザレコード２１４には、アカウントデータ２１５、セーブデータ２１６等が含まれている

【0094】

アカウントデータ２１５は、各ユーザのアカウントに関する情報であり、各ユーザを一意に識別するための情報としても用いられる。また、アカウントデータ２１５は、ログイン処理にも用いられる。

【0095】

セーブデータ２１６は、各ユーザのゲームのプレイ状況、進行状況等をセーブした情報である。また、セーブデータ２１６には、そのユーザが所属している仮想クラブを特定するための情報等も含まれる。

【0096】

図６に戻り、次に、仮想クラブデータベース２０５は、上記仮想クラブに関するデータベースである。図８は、当該仮想クラブデータベース２０５のデータ構成の一例を示す図である。仮想クラブデータベース２０５は、複数の仮想クラブレコード２２１で構成されている。各仮想クラブレコード２２１には、仮想クラブＩＤ２２２、オーナーデータ２２３、所持通貨データ２２４、ホームスタジアムデータ２２５、メンバーデータ２２９が少なくとも含まれている。

【0097】

仮想クラブＩＤ２２２は、各仮想クラブを一意に識別するためのＩＤである。

【0098】

オーナーデータ２２３は、その仮想クラブのオーナーであるユーザを特定するための情報である（デフォルトでは、仮想クラブの作成ユーザが設定される）。

【0099】

所持通貨データ２２４は、その仮想クラブが所有する上記ゲーム内通貨を示すデータである（いわば、クラブの資金として記憶されるものである）。本ゲームでは、上記のようにスタジアムパーツを購入することでカスタマイズが可能である。そのため、スタジアムパーツ購入のために利用できるゲーム内通貨は、各仮想クラブに関連づけられることになる。なお、これとは別に、各ユーザが各自で利用可能なゲーム内通貨があってもよい。

【0100】

ホームスタジアムデータ２２５は、その仮想クラブが有するホームスタジアムに関するデータである。ホームスタジアムデータ２２５には、少なくとも、スタジアムランクデータ２２６、右半分構成データ２２７、左半分構成データ２２８が含まれる。スタジアムランクデータ２２６は、当該ホームスタジアムの現在のスタジアムランクを示すデータである。右半分構成データ２２７は、ホームスタジアムの上記右半分部分の構成を示すデータである。具体的には、ホームスタジアムの右半分部分で用いられているスタジアムパーツを特定する情報、および、その配置位置や姿勢を特定する情報が少なくとも含まれている。左半分構成データ２２８も同様で、ホームスタジアムの上記左半分部分の構成を示すデータである。また、所定のカスタマイズ画面等において、ユーザが、購入済みのスタジアムパーツをホームスタジアムに適用する操作を行うことで、ホームスタジアムの構成内容が変更され、当該ホームスタジアムデータ２２５の内容が適宜更新され得る。

【0101】

なお、本実施形態では、ホームスタジアムデータ２２５の構成について、上記のように右半分構成データと左半分構成データを分ける例で説明するが、他の実施形態では、右半分構成データおよび左半分構成データというデータ構成ではなくてもよい。例えば、スタジアム全体のデータから、スタジアムの右半分部分、左半分部分に対応するデータを適宜選択して、スタジアム右半分の構成、スタジアム左半分の構成を示すデータを特定してもよい。

【0102】

メンバーデータ２２９は、その仮想クラブに所属しているユーザを示すための情報である。

【0103】

その他、図示は省略するが、仮想クラブレコード２２１には、その仮想クラブの名称やエンブレム等を示すデータも含まれる。

【0104】

図６に戻り、その他のゲーム関連データ２０６は、上記のようなゲーム処理において用いられる各種のデータである。上記ログイン処理のタイミングやゲーム中の所定のタイミングにおいて、必要に応じてその他のゲーム関連データ２０６から抽出されたデータがサーバからゲーム装置２に送信される。

【0105】

次に、ゲーム装置２で用いられるデータに関して説明する。図９は、ゲーム装置２の記憶部２２に格納されるプログラムおよびデータの一例を示すメモリマップである。記憶部２２には、プログラム記憶領域３０１およびデータ記憶領域３０３が含まれている。プログラム記憶領域３０１には、ゲーム処理プログラム３０２が記憶される。また、データ記憶領域３０３には、ユーザデータ３０４、所属クラブデータ３０５、既定スタジアムデータ３０６、アイテムマスタデータ３０７、抽選テーブル３０８、試合制御用データ３０９、仮想カメラ制御用データ３１４、操作データ３１５、送信用データ３１６、受信データ３１７等のデータが記憶される。

【0106】

ゲーム処理プログラム３０２は、本実施形態にかかるゲーム処理を実行するためのプログラムである。

【0107】

ユーザデータ３０４は、ゲーム装置２を使用しているユーザに関するデータである。上記ログイン処理の際に、ユーザデータベース２０４から当該ユーザに対応する所定の情報が選択されるデータであり、これをサーバから受信して記憶したものである。例えば、ユーザ名等が含まれている。

【0108】

所属クラブデータ３０５は、ユーザが所属している仮想クラブに関するデータである。当該所属クラブデータ３０５は、例えばログイン処理の際に、上記仮想クラブデータベース２０５からログインしたユーザに応じて選択された仮想クラブレコード２２１をサーバから受信して記憶したものである。

【0109】

既定スタジアムデータ３０６は、本ゲームにおいて最初から用意されている上記既定スタジアムに関するデータである。既定スタジアムデータ３０６には、既定スタジアムの外観構成を示すデータ等が含まれている。

【0110】

アイテムマスタデータ３０７は、上述したような各種のアイテムについて定義したマスタデータである。アイテムマスタデータ３０７には、アイテム毎に、そのアイテムの識別子、外観、効果、共用アイテムか専用アイテムかを示す情報、等が含まれる。

【0111】

抽選テーブル３０８は、上記アイテムボックスとして投入するアイテムを抽選するために用いられるデータであり、各アイテムの当選率を定義したデータである。

【0112】

なお、上記既定スタジアムデータ３０６、アイテムマスタデータ３０７、抽選テーブル３０８は、上記サーバの、その他のゲーム関連データ２０６に含まれていてもよい。そして、ログイン処理等の所定のタイミングで、サーバからこれらのデータを受信および記憶してもよい。あるいは、ゲーム装置２におけるゲームアプリケーションの一部として記憶しておき、ゲームアプリケーションの起動時等に、記憶部２２に読み込むようにしてもよい。

【0113】

次に、試合制御用データ３０９は、上記のような試合に係る処理を制御するために、ゲーム処理中に適宜生成されて用いられるデータである。試合制御用データ３０９には、選手キャラクタデータ３１０、試合状況管理データ３１１、熱中度管理データ３１２、合体スタジアムデータ３１３が少なくとも記憶される。

【0114】

選手キャラクタデータ３１０は、上記選手キャラクタに関するデータである。選手キャラクタデータ３１０には、各選手キャラクタの現在位置や姿勢、現在の動作状態（例えばシュート中、ドリブル中等の状態）等、試合中の各選手キャラクタの動作を制御するための各種のデータが含まれている。

【0115】

試合状況管理データ３１１は、試合全般を管理するためのデータである。試合状況管理データ３１１には、例えば、次のようなデータが含まれる。まず、試合の参加ユーザ（および他のゲーム装置２）を特定するためのデータが含まれる。また、各ユーザの担当チームを示すデータも含まれる、また、試合中において各ユーザの現在の操作対象となっている選手キャラクタを示すデータも含まれる。また、上記アイテム投入の時間を管理するためのデータも含まれる。また、現在の得点状況を示すデータや、試合開始からの経過時間を示すデータ等、試合の進行等を管理・制御するための各種データが含まれる。

【0116】

熱中度管理データ３１２は、上述したような熱中度を管理するためのデータである。熱中度管理データ３１２には、対戦する２つのチーム（自チーム／敵チーム）別に、現在の熱中度を示すデータが含まれている。

【0117】

合体スタジアムデータ３１３は、試合で用いる上記合体スタジアムに関するデータである。例えば、合体スタジアムに係るスタジアムの組み合わせを特定する情報、あるいは、合体スタジアムのオブジェクトデータそのもの、等が記憶される。

【0118】

次に、仮想カメラ制御用データ３１４は、仮想カメラの動きを制御するためのデータである。具体的には、仮想カメラ位置・姿勢、画角、撮像方向等を指定するデータである。試合中は、基本的には、ユーザが操作している選手キャラクタが画面の略中央に映るように、自動的に仮想カメラ制御用データ３１４の内容が設定される。その他、ユーザによる仮想カメラの操作に基づいて仮想カメラ制御用データ３１４が設定されてもよい。その他、上記スタジアム合体演出等の演出を表示する際は、各演出用のカメラワークを定義したデータに基づき、仮想カメラ制御用データ３１４が設定される。

【0119】

操作データ３１５は、コントローラ４に対して行われた操作の内容を示すデータである。例えば、十字キー等のボタン部４３に対する押下状態や、上記アナログスティック４２に対する入力状態を示すデータが含まれる。当該操作データ３１５の内容は、コントローラ４（通信部４１）からの信号に基づき、所定の周期で更新される。

【0120】

送信用データ３１６は、他のゲーム装置２に送信するためのデータであり、少なくとも、送信元を特定するための情報と、上記操作データ３１５の内容を含むデータである。

【0121】

受信データ３１７は、他のゲーム装置２から受信した上記送信用データ３１６を、当該他のゲーム装置毎に（つまり、送信元が）識別可能なように記憶したデータである。

【0122】

その他、記憶部２２には、ゲーム処理で用いられる各種のデータが必要に応じて記憶される。例えば、選手キャラクタや観客の外観を示すモデリングデータ等が記憶される。

【0123】

［プロセッサ２１が実行する処理の詳細］
次に、本実施形態にかかるゲーム処理の詳細を説明する。ここでは主に、ユーザＶＳユーザの形式で試合（２人のユーザによる対戦プレイ）を行う場合の処理について説明する。

【0124】

図１０は、ゲーム処理の詳細を示すフローチャートである。当該ゲーム処理は、例えば、所定のメニュー画面において、ユーザが対戦プレイを指示する操作を行うことで、その実行が開始される。なお、当該フローチャートは、処理過程の単なる一例にすぎない。そのため、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判定ステップで利用される閾値も、単なる一例であり、必要に応じて他の値を採用してもよい。

【0125】

図１０において、まず、ステップＳ１で、プロセッサ２１は、試合準備処理を実行する。当該処理は、試合を開始するための各種の準備を行う処理である。図１１は、当該試合準備処理の詳細を示すフローチャートである。図１１において、まず、ステップＳ１１で、プロセッサ２１は、対戦ユーザを決定するための処理を実行する。ここでは、ユーザ同士で対戦する場合を例として説明するが、ユーザは、対戦相手としてＣＰＵを選んでもよいし、ＣＰＵ同士の対戦としてもよい。ユーザ同士で対戦する場合は、上記サーバを介した所定のマッチング処理や、フレンドを招待する処理等により、試合の参加ユーザ（ここでは合計２人のユーザ）を確定する処理が実行される。そして、プロセッサ２１は、確定した参加ユーザ（以下、対戦相手）に関する情報（所属クラブ等）と、その対戦相手が用いるゲーム装置２を特定するための情報（ネットワークアドレス情報等）を示す情報等を、試合状況管理データ３１１として記憶する。

【0126】

次に、ステップＳ１２で、プロセッサ２１は、試合に用いるスタジアムを決定する処理を実行する。ここでは、例えば以下のような処理が実行される。まず、プロセッサ２１は、対戦相手が所属する仮想クラブを試合状況管理データ３１１に基づいて特定する。次に、対戦相手の仮想クラブに係るホームスタジアムデータ２２５をサーバから取得する。次に、プロセッサ２１は、ユーザ自身のホームスタジアムのデータおよび対戦相手のホームスタジアムのデータと、既定スタジアムデータ３０６とに基づいて、スタジアム一覧画像を生成し、表示部５に表示する。そして、プロセッサ２１は、ユーザからの選択操作を待ち受ける。そして、ユーザが、当該スタジアム一覧から、使用するスタジアムを２つ選択する操作を行うことで、その操作内容に基づき、２つのスタジアムが使用スタジアムとして決定される。ここでは、ユーザおよび対戦相手それぞれのホームスタジアムが選択された場合を例として説明する。なお、選択操作に関して、ユーザが１人で２つのスタジアムを選択してもよいし、ユーザと対戦相手とが順番に１つずつスタジアムを選択する操作を行ってもよい。

【0127】

次に、ステップＳ１３で、プロセッサ２１は、上記選択された２つのホームスタジアムを合体させて上記合体スタジアムを生成する処理を実行する。例えば、プロセッサ２１は、ユーザのホームスタジアムデータ２２５の右半分構成データ２２７に基づき、右半分だけのホームスタジアムのオブジェクトを構成する。更に、対戦相手のホームスタジアムデータ２２５の左半分構成データ２２８に基づき、左半分だけのホームスタジアムのオブジェクトを構成する。そして、プロセッサ２１は、両者を合体させることで、１つの合体スタジアムのオブジェクトを生成し、上記合体スタジアムデータ３１３として記憶する。この際、各スタジアムの断面部分における上記フィールドの中心部分が同じ座標軸上で隣接するように合体させる。上記のように各スタジアムのフィールドのサイズは共通であるため、どのスタジアムを合体させたとしても、フィールド部分についてはズレが生じずに、共通のサイズのフィールドとなる。

【0128】

次に、ステップＳ１４で、プロセッサ２１は、各種オブジェクトを（試合を行うための）仮想空間に配置する。具体的には、プロセッサ２１は、合体スタジアムのフィールド上に選手キャラクタを配置する。また、プロセッサ２１は、合体スタジアムに係るホームスタジアムのそれぞれの観客席（観客配置領域）上に観客も配置する。この際、プロセッサ２１は、スタジアムランクに応じた種類の観客を適宜選択して配置する。上記のように、観客席の規模はスタジアムランクが高いほど大きく、また、常に満席状態となるよう観客を配置する。その結果、それぞれのスタジアムランクの高さに応じた数の観客が配置されることになる。そのため、合体スタジアムを構成する２つのスタジアムの間で、観客数に差が出ることもあり得る。その他、プロセッサ２１は、ボールや審判キャラクタ等の各種オブジェクトも適宜配置する。また、これに伴い、プロセッサ２１は、試合中に用いる各種データの初期化処理も行う。

【0129】

次に、ステップＳ１５で、プロセッサ２１は、合体スタジアムデータ３１３に基づき、上記のようなスタジアム合体演出も表示する。すなわち、プロセッサ２１は、上記のように、ユーザのホームスタジアムの半分部分と、対戦相手のホームスタジアムの半分部分とを、仮想空間内で互いに離れた位置に出現させる。更に、それぞれを互いに近づくように移動させていく。そして、断面部分が接触することで、１つの合体スタジアムが完成する、という演出を表示部５に表示する。

【0130】

次に、ステップＳ１６で、プロセッサ２１は、（上記スタジアム合体演出に引き続いて）試合開始を告げる所定の演出を表示する。当該試合開始の演出表示が終われば、試合準備処理は終了し、試合が開始される。

【0131】

図１０に戻り、次に、ステップＳ２で、プロセッサ２１は、試合制御処理を実行する。図１２は、当該試合制御処理を詳細を示すフローチャートである。まず、ステップＳ２１で、プロセッサ２１は、アイテム投入制御処理を実行する。この処理は、上記のようなアイテムの投入を制御するための処理である。

【0132】

図１３は、当該アイテム投入制御処理の詳細を示すフローチャートである。まず、ステップＳ３１で、プロセッサ２１は、チーム（仮想クラブ）毎に、スタジアムランクデータ２２６および、熱中度管理データ３１２に基づいて、次回のアイテム投入のタイミングを算出する。算出手法はどのようなものでもよいいが、例えば、プロセッサ２１は、スタジアムランクデータ２２６に基づき、上記初期投入間隔を算出する。そして、プロセッサ２１は、現在の熱中度に応じて当該間隔を所定の時間、短縮することで、次回の投入タイミングを決定する。

【0133】

なお、上記のように、スタジアムランクに応じて投入間隔は異なるため、ランクが異なるホームスタジアムが合体している場合は、仮想クラブ毎に上記アイテムの投入間隔が異なることもあり得る。

【0134】

次に、ステップＳ３２で、プロセッサ２１は、試合状況管理データ３１１に含まれる試合経過時間の情報に基づき、上記次回の投入タイミングが到来したか否かを判定する。当該判定の結果、到来していない場合は（ステップＳ３２でＮＯ）、プロセッサ２１は、当該アイテム投入制御処理を終了する。一方、到来している場合は（ステップＳ３２でＹＥＳ）、ステップＳ３３で、プロセッサ２１は、アイテムマスタデータ３０７および抽選テーブル３０８に基づき、投入するアイテムを１つ抽選する。この際、プロセッサ２１は、試合状況管理データ３１１に基づき、例えば得点状況等を参照して、その時点で不利な試合展開となっている仮想クラブにとってより有利な効果となるようなアイテムが抽選されやすくなるような調整を行ってもよい。例えば、専用アイテムの当選率を一時的に倍にする等の調整を行ってもよい。

【0135】

次に、ステップＳ３４で、プロセッサ２１は、上記抽選されたアイテムが入ったアイテムボックスを生成し、当該アイテムボックスを投入する位置を決定する。本実施形態では、上記のように、アイテムボックスを投入する観客の応援クラブに属する選手キャラクタの位置またはその近傍位置を投入位置として決定する。

【0136】

次に、ステップＳ３５で、プロセッサ２１は、上記アイテムボックスを上記決定された投入位置に向けて観客席（観客配置領域内の所定の位置）から投入する処理を実行する。例えば、プロセッサ２１は、所定の観客席の位置を始点とし、上記投入位置を目標点として、放物線を描くようにアイテムボックスを移動させる処理を実行する。なお、上記のように、対戦している２つの仮想クラブ毎にアイテム投入の制御が行われるため、タイミング次第では、２つのアイテムボックス（ユーザの仮想クラブに係るものと、対戦相手の仮想クラブに係るもの）が同時に投入されることもあり得る。

【0137】

以上で、アイテム投入制御処理は終了する。

【0138】

図１２に戻り、次にステップＳ２２で、プロセッサ２１は、選手キャラクタの動作制御を行う。具体的には、以下のような処理が行われる、まず、プロセッサ２１は、操作データ３１５を取得する。次に、その操作内容に基づき、現在操作対象となっているいずれか１体の自チーム側の選手キャラクタの動作を制御する。また、残りの自チーム側の選手キャラクタについては、ＡＩ制御を行う。次に、プロセッサ２１は、当該操作データ３１５を含む送信用データ３１６を生成して、対戦相手のゲーム装置２に送信する。次に、プロセッサ２１は、対戦相手のゲーム装置２から対戦相手の操作データ３１５を含むデータを受信し、受信データ３１７として記憶する。そして、プロセッサ２１は、受信データ３１７に基づき、対戦相手の選手キャラクタの動作を制御する。

【0139】

次に、ステップＳ２３で、プロセッサ２１は、ボールの移動制御を行う。具体的には、プロセッサ２１は、ボールに関連付けられて設定されている移動用パラメータ（移動方向、移動速度等）に基づいて、ボールを移動させる。

【0140】

次に、ステップＳ２４で、プロセッサ２１は、各種の衝突判定、および、その判定結果に基づくゲーム処理を実行する。具体的には、少なくとも以下の３種類の衝突判定およびゲーム処理が行われる。

【0141】

まず、ボールについての衝突判定が行われる。すなわち、ボールが選手キャラクタ等と衝突した場合（例えばドリブル、パス、シュート等）、その衝突の内容に基づいて、ボールの上記移動用パラメータを設定する処理が実行される。

【0142】

次に、選手キャラクタ同士の衝突判定が行われる。例えば、選手キャラクタが他の選手キャラクタにタックルした場合等である。この場合も、その衝突結果に基づき、選手キャラクタの動作制御用のパラメータが適宜設定される。例えば、タックルによって吹き飛ばされるという動作制御を行うための各種パラメータ設定が行われる。

【0143】

更に、上記アイテムボックスまたはアイテムとの衝突（接触）判定も行われる。この場合は、アイテムボックスへの衝突があった場合は、その場に上記抽選されたアイテムを出現させ、当該衝突した選手キャラクタ（の属するチーム）にそのアイテムを取得させる処理も行われる。

【0144】

上記のように各種の衝突判定が行われ、その判定結果に基づいたゲーム処理が適宜実行される。

【0145】

次に、ステップＳ２５で、プロセッサ２１は、上記のような衝突判定結果に基づかない、その他のゲーム処理を実行する。本実施形態では、少なくとも以下のような処理が行われる。

【0146】

まず、上記熱中度の変化に関する処理が実行される。プロセッサ２１は、熱中度を上昇させるための所定の条件が達成されたか否かを判定する。達成されていれば、プロセッサ２１は、達成した内容、および、条件を達成した仮想クラブのスタジアムランクに基づいて、熱中度を所定値上昇させ、熱中度管理データ３１２を更新する。

【0147】

更に、取得されたアイテムの使用に関する処理も実行される。具体的には、プロセッサ２１は、ユーザによってアイテム使用操作が行われた場合、使用指示されたアイテムに応じた所定の効果を発生させる処理を行う。

【0148】

更に、得点判定の処理も実行される。すなわち、プロセッサ２１は、ボールがゴール内に移動したか否かを判定し、その内容に応じていずれかの仮想クラブに得点を与える処理（試合状況管理データ３１１の更新）を行う。

【0149】

その他、観客の応援モーションの制御や、仮想カメラ制御用データ３１４の設定、音声再生制御の処理等も実行される。ここで、観客の応援モーションについては、上記熱中度に応じて変化させるようにしてもよい。例えば、熱中度が高いほうが熱中度が低いときよりも動きの激しい応援モーションを観客に行わせる、等である。これにより、熱中度が高くなるにつれて観客も盛り上がっていく様を提示し、観客との一体感をユーザに体感させることができる。

【0150】

次に、ステップＳ２６で、プロセッサ２１は、上記の処理内容を反映したゲーム画像を生成し、表示部５に出力する。以上で、試合制御処理は終了する。

【0151】

図１０に戻り、次に、ステップＳ３で、プロセッサ２１は、試合終了条件が満たされたか否かを試合状況管理データ３１１に基づいて判定する。例えば、試合時間が終了したか否かが判定される。当該判定の結果、試合終了条件が満たされていない場合は（ステップＳ３でＮＯ）、上記ステップＳ２に戻り、処理が繰り返される。一方、試合終了条件が満たされた場合は（ステップＳ３でＹＥＳ）、ステップＳ４で、プロセッサ２１は、試合終了処理を実行する。

【0152】

図１４は、試合終了処理の詳細を示すフローチャートである。図１４において、まず、ステップＳ４１で、プロセッサ２１は、試合の結果に基づき、対戦した各仮想クラブに対して付与するゲーム内通貨の額を算出する。そして、プロセッサ２１は、算出された額のゲーム内通貨を各仮想クラブに付与する（所持通貨データ２２４の更新）。

【0153】

次に、ステップＳ４２で、プロセッサ２１は、スタジアムランクのアンロック制御を行う。すなわち、プロセッサ２１は、上記試合の結果、今回対戦した各クラブについて、上位ランクのアンロック条件が満たされたか否かを判定し、満たされていれば、上位ランクをアンロックする処理を行う。また、これに伴い、プロセッサ２１は、スタジアムランクデータ２２６を上位ランクに更新する。これにより、ユーザは、上位ランクのスタジアムパーツを購入可能な状態とすることができる。なお、この際に、プロセッサ２１は、スタジアムランクが上がったことを示す所定の演出を表示してもよい。

【0154】

次に、ステップＳ４３で、プロセッサ２１は、試合終了の演出を表示部５に表示する。以上で、試合終了処理が終了する。

【0155】

以上で、本実施形態にかかるゲーム処理の詳細説明を終了する。

【0156】

このように、本実施形態では、ユーザが作成した仮想クラブ同士で対戦を行うことができる。また、各仮想クラブのホームスタジアムには、スタジアムランクという成長要素が設定されている。更に、ユーザは、観客が配置される観客席を上記スタジアムパーツとして購入可能である。この観客席については、スタジアムランクを上げることで、より多くの観客が配置可能な観客席を購入できる。また、当該観客は、所定の時間間隔でゲームに有利な効果を発生させるアイテムを投入するが、この投入間隔は、スタジアムランクが上がるに連れて短縮される。そのため、スタジアムランクを上げることで、このようなアイテムを利用可能な機会を増やすことができ、その分、ゲームをより有利に進めやすくすることができる。これにより、スタジアム（仮想クラブ）を成長させる楽しみや動機付けをユーザに提供し、ゲームの興趣性を高めることができる。また、自分のクラブを応援する観客が増えることで、より有利にゲームを進めやすくなるという関係性をユーザに提示でき、自分のクラブの観客（サポーター）が増えることによる恩恵や観客との一体感をユーザに体験させることができる。これにより、スポーツゲームとしての興趣性をより高め、仮想クラブを成長させる楽しさをユーザに提供できる。

【0157】

また、本実施形態では、２つのスタジアムを合体させた合体スタジアムを試合に用いている。これにより、例えば、異なる仮想クラブ同士で対戦する場合、お互いのホームスタジアムを合体させた合体スタジアムで試合を行うことができる。また、上記アイテムの投入間隔等は、それぞれのクラブのスタジアムランク毎に制御されるため、各クラブのホームスタジアムに応じた効果を発生あるいは付与させることができる。更に、本実施形態では、スタジアム合体演出を試合前にユーザに提示している。これにより、試合を行うための一連の操作において、各クラブがカスタマイズしたホームスタジアムをお互いに見せ合うという楽しみ方を提供できる。また、試合前に対戦相手のスタジアムランクを確認させることもできる。

【0158】

［変形例］
なお、上記実施形態では、上記アイテムボックスとして抽選される内容についてはスタジアムランクの影響を受けない例を示した。他の実施形態では、投入されるアイテムをスタジアムランクに応じて変化させてもよい。例えば、スタジアムランク１では投入（抽選）されることはないが、スタジアムランク４では投入され得るようなアイテムがあってもよい。

【0159】

また、（少なくとも見た目は）同じアイテムであっても、その効果量や効果の大きさをスタジアムランクに応じて変化させてもよい。例えば、アイテムの一例として、選手キャラクタの移動速度を一時的に高めるアイテムを想定する。この場合に、スタジアムランク１のときに投入されたものよりも、スタジアムランク４のときに投入されたもののほうが、移動速度の上昇量がより大きくなるようにしてもよい。これにより、スタジアムランクが高くなるにつれて、より有利に試合を進めることが可能となる。

【0160】

また、更に他の実施形態では、仮想クラブの対戦成績に応じて、選手キャラクタの性能を変化させるようにしてもよい。例えば、累計勝利数が所定の閾値を越えると、その後は、その仮想クラブの選手キャラクタの「移動速度」パラメータに所定値が加算されるようにしてもよい。これにより、対戦成績が上がることで、より有利に試合を進めることが可能となる。

【0161】

また、上記実施形態では、スタジアムランクについては、上位ランクのアンロック条件が満たされた場合、上位ランクがアンロックされてスタジアムランクが自動的に上がる例を示した。他の実施形態では、上位ランクのアンロック条件（スタジアムランク更新条件）が満たされても、すぐにはスタジアムランクの更新は行わず、ユーザによる所定の操作に基づいて、所定のタイミングでスタジアムランクが更新可能なようにしてもよい。例えば、ゲーム内通貨を所定額消費することと引き換えに、上位ランクをアンロックしてスタジアムランクを更新するようにしてもよい。

【0162】

また、上記実施形態では、上位ランクがアンロックされることで、アンロックされたランクに応じた上記スタジアムパーツが購入可能な状態となる例を示した。他の実施形態では、上位ランクがアンロックされている状態でも、現在のランクよりも上位のランクに応じたスタジアムパーツの購入自体は可能としてもよい。この場合、購入はできるものの、そのスタジアムパーツに応じたスタジアムランクになるまでは、使用できないようにすればよい。

【0163】

また、更に他の実施形態では、上記のようなスタジアムランクとは別に、クラブ自体のランクを示す「クラブランク」を示すデータを用いるようにしてもよい。そして、クラブランクは、例えば対戦成績（勝利数）に基づいて上がるようにしてもよい。この場合、上記スタジアムランクデータ２２６とクラブランクを示すデータとを関連付けるようにして記憶させてもよい。そして、クラブランクに応じて、スタジアムランクを更新、または、ユーザ操作に基づいて更新可能な状態としてもよい。

【0164】

また、スタジアム合体に関して、他の実施形態では、合体スタジアムが特定のスタジアムの組み合わせである場合に、特殊合体として、特別な効果を発生させたり、特別な演出を提示させたりしてもよい。例えば、同じ「テーマ」を適用しているスタジアム同士が組み合わされて合体スタジアムが生成される場合、スタジアム合体演出において特別な演出表示を行ったり、試合開始演出で特別なＢＧＭを再生したりしてもよい。同じ「テーマ」のスタジアムであっても、各々のスタジアムに関連付けられた観客席オブジェクトや観客オブジェクト等のスタジアムパーツは異なっていてもよい。また、その他、、「テーマＡ」を適用しているスタジアムと「テーマＢ」を適用しているスタジアムが組み合わされて合体スタジアムが生成される場合であっても、これらのスタジアムの組み合わせが、特殊合体として予め定義されている組み合わせである場合は、スタジアム合体演出において特別な演出表示を行ったり、試合開始演出で特別なＢＧＭを再生したりしてもよい。更には、投入されるアイテムについても、このような特殊合体による合体スタジアムでしか投入されないような特別なアイテムを設けてもよい。

【0165】

また、上記ホームスタジアムについて、投入されるアイテム（すなわち、発生させる効果）を、ユーザがある程度選択可能なものとしてもよい。例えば、投入アイテムについても上記スタジアムパーツの１種として、ゲーム内通貨を用いて購入可能としてもよい。更に、購入した投入アイテムの中から、実際に試合中に投入される対象として所定の投入アイテムを指定できるようにしてもよい。これにより、各仮想クラブのホームスタジアム毎に投入されるアイテムを異ならせることができ、各ホームスタジアムに個性を持たせることができる。

【0166】

また、上記既定スタジアムに関して、投入されるアイテムの種類を既定スタジアム毎に異ならせるようにしてもよい。すなわち、投入されるアイテムの少なくとも一部について、既定スタジアム毎に定義されている固有のアイテムが投入されるようにしてもよい。

【0167】

また、上記実施形態では、スタジアムを合体させる際、半分の大きさのスタジアム同士を合体させる例を挙げた。つまり、スタジアムの大きさについて、５０％同士のものを合体させる例を挙げていた。他の実施形態では、５０％同士の割合で合体させることに限らず、例えば、一方が７５％、他方が２５％の割合で合体させるようにしてもよい。

【0168】

また、上記実施形態では、２つのスタジアムを合体させる場合を例示したが、他の実施形態では、３つ以上のスタジアムを合体させてもよい。例えば、４つのスタジアムを合体させる場合は、各スタジアムの割合が２５％となるように、各スタジアムの一部を抽出して合体させてもよい。また、合体に際して指定するスタジアムの数に関しては、ゲームに参加するユーザ（または仮想クラブ）に応じた数であってもよい。また、スタジアムの指定について、例えば４人で対戦プレイする場合は、各ユーザが１つずつスタジアムを指定できるようにしてもよい。あるいは、１人のユーザが複数のスタジアムを指定するようにしてもよい。

【0169】

また、アイテムの投入間隔に関して、上記実施形態では、スタジアムランクに加えて「熱中度」を考慮して調整する例を示した。他の実施形態では、このような「熱中度」というパラメータは必ずしも用いずともよい。例えば、上述したような熱中度上昇条件として予め定義されている所定のプレイが行われた回数をカウントしておき、そのカウント数が所定の閾値を越えたことに基づいて、アイテムの投入間隔を更に短縮するような制御を行ってもよい。つまり、当該所定のプレイの実行状況に基づいて、アイテムの投入間隔を調整してもよい。

【0170】

また、上記実施形態では、サッカー等のゴールにボールを入れ合うような球技を例に説明したが、この他、上記のようなゴールを用いない球技のゲームに、上記の処理を適用してもよい。例えば、野球をモチーフにしたゲームに適用してもよい。この場合、上記合体スタジアムに関していうと、球場には自陣・敵陣の概念はないものの、例えば球場を所定の方向に沿って２等分し、片方ずつを合体させて、「合体球場」を生成してもよい。また、上記仮想クラブに相当するものとして、「仮想球団」をユーザが作成したり、ユーザが所属可能としてもよい。

【0171】

また、合体スタジアムに関しては、球技以外のゲームに適用してもよい。例えば、ユーザが育成したキャラクタ同士をスタジアムで対戦させるような対戦ゲームに適用してもよい。また、例えば、格闘技をモチーフにしたゲームであって、対戦場所（ステージ）として、上記スタジアムに相当するような場所が複数の中から選択可能な対戦ゲームに適用してもよい。

【0172】

また、上記実施形態においては、試合に係る一連のゲーム処理が単一のゲーム装置２で実行される場合を説明した。他の実施形態においては、上記一連の処理が複数の情報処理装置からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの一部の処理がサーバ側装置によって実行されてもよい。更には、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。また、いわゆるクラウドゲーミングの構成としてもよい。例えば、ゲーム装置２は、ユーザの操作を示す操作データを所定のサーバに送り、当該サーバにおいて各種ゲーム処理が実行され、その実行結果が動画・音声としてゲーム装置２にストリーミング配信されるような構成としてもよい。

【符号の説明】

【0173】

２ ゲーム装置
４ コントローラ
５ 表示部
２１ プロセッサ
２２ 記憶部
２３ 無線通信部
２４ コントローラ通信部
２５ 画像音声出力部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】