JP2020127711A - ゲームプログラム、ゲーム装置、ゲームシステム、およびゲーム処理制御方法 - Google Patents

Abstract

【課題】対戦ゲームの戦術に関する興趣性をより高めることが可能なゲームプログラム、ゲーム装置、ゲーム処理方法、ゲームシステムを提供すること。【解決手段】ユーザの対戦相手に関連する第２ゲーム処理とは独立して進行する第１ゲーム処理を実行する。また、複数の対戦相手に関連する第２ゲーム処理の第２ゲーム状況を示す状況データを逐次取得し、第１ゲーム処理の第１ゲーム状況を反映した第１画像と、状況データが示す第２ゲーム状況を反映した画像である複数の第２画像とを含む表示用画像を逐次生成する。複数の対戦相手の中から少なくとも１を選択するための方針をユーザの操作に基づいて選択し、選択された方針に基づいて、複数の対戦相手から標的を特定し、ユーザのゲーム状況が所定の条件を満たす場合、標的のゲーム状況を変化させるための指示を行う。【選択図】図２７

Description

本発明は、対戦ゲームにおけるゲーム処理に関し、より特定的には、攻撃対象とする対戦相手を特定する処理に関する。

従来から、いわゆる落ちものゲームで対戦するゲームが知られている（例えば特許文献１）。また、このゲームでは、プレイヤ２人で１チームを組み、２ｖｓ２でのチーム対戦が可能となっている。また、このゲームでは、第１のチーム内の一方のプレイヤが、他方のプレイヤのゲームフィールドの所定範囲に蓄積されたボールをブロックとして引き取ること可能となっている。また、これにより、蓄積されたボールがゲームフィールドの上端に到達することを回避できたり、一方のプレイヤが他方のプレイヤのボールを利用して、相手チームに対して攻撃を加えることができることも開示されている。

特開２０１１−５５９８１号公報

しかし、上記の技術においては、対戦相手となるチームは１つだけであるため、攻撃する相手を選択する余地は実質的に無い、あるいは乏しいものであった。言い換えれば、各プレイヤで独立してゲームが進行するゲームにおいて、攻撃の標的対象となる相手の選択方法が乏しかった。つまり、攻撃相手の選択という点での対戦ゲームの戦術に関する興趣性について改良する余地があった。

それ故に、本発明の目的は、対戦ゲームの戦術に関する興趣性をより高めることが可能なゲームプログラム、ゲーム装置、ゲーム処理方法、ゲームシステムを提供することである。

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

構成例の一例は、ユーザに対戦ゲームを提供するための情報処理装置のコンピュータにおいて実行されるゲームプログラムであって、前記コンピュータを、ゲーム実行手段と、取得手段と、画像生成手段と、方針選択手段と、特定手段と、変化指示手段として機能させる。ゲーム実行手段は、当該ユーザの対戦相手に関連する第２ゲーム処理とは独立して進行する第１ゲーム処理をユーザの操作に基づいて実行する。取得手段は、複数の対戦相手に関連する第２ゲーム処理の第２ゲーム状況を示す状況データを逐次取得する。画像生成手段は、第１ゲーム処理の第１ゲーム状況を反映した画像である第１画像と、取得手段によって取得した複数の状況データが示す第２ゲーム状況を反映した画像である複数の第２画像とを含む表示用画像を逐次生成する。方針選択手段は、複数の対戦相手の中から少なくとも１を選択するための方針であって、予め設定されている複数の方針のうち、ユーザの操作に基づいていずれか１の方針を選択する。特定手段は、選択された方針に基づいて、複数の対戦相手のうち、少なくとも１を標的として特定する。変化指示手段は、ユーザのゲーム状況が所定の条件を満たす場合、特定手段によって標的として特定された対戦相手のゲーム状況を変化させるための指示を行う。

上記構成例によれば、ユーザは対戦相手とは独立して進行するゲーム処理を行いながらも、複数の対戦相手のうちのどの対戦相手のゲーム状況を変化させるかについて、ユーザの選択した方針に基づいて選択することができるため、対戦ゲームの戦術に関する興趣性を向上させることができる。特に、多数の対戦相手から所定の対戦相手を選択したい場合に、ユーザの意思を反映した速やかな選択が可能となる。

他の構成例として、取得手段は、複数の対戦相手のそれぞれがユーザを標的として特定しているか否かを示す被特定情報データを含む状況データを逐次取得し、画像生成手段は、対戦相手がユーザを標的として特定していることを被特定情報データが示す場合、当該対戦相手が当該ユーザを標的として特定していることを判別可能とするための第３画像を含む表示用画像を逐次生成してもよい。

上記構成例によれば、ユーザがどの対戦相手から標的にされているのかを判別しやすくすることができ、ゲームの緊迫感を向上することできる。

他の構成例として、画像生成手段は、取得手段が取得した状況データに基づいて、複数の対戦相手それぞれの順位が判別可能な表示を含むように第２画像を生成して表示用画像に含めるようにしてもよい。

他の構成例として、画像生成手段は、対戦相手がゲームを続行できない状況となった場合、当該対戦相手がゲームを続行できない状況になった時点で確定した順位が判別可能な表示を含むように第２画像を生成して表示用画像に含めるようにしてもよい。

上記構成例によれば、対戦相手の順位をユーザに把握させることができ、対戦ゲーム全体の進行状況を判別しやすくすることができる。

他の構成例として、取得手段は、ユーザのゲーム状況がゲームの続行ができない状況となった後も状況データの逐次取得を継続してもよい。更に、画像生成手段は、ユーザのゲーム状況がゲームの続行ができない状況となった後も、状況データに基づいて第２画像を含む表示用画像を逐次生成してもよい。

上記構成例によれば、ユーザは、自身が対戦ゲームに敗北した後も、対戦相手全員にかかるその後のゲーム状況を確認できる。これにより、ユーザがゲームに敗北した後でも、自身が参加した対戦ゲームのその後の状況・展開を楽しませることができる。

他の構成例として、画像生成手段は、第１領域に第１画像を配置し、第２領域に複数の第２画像のそれぞれを配置するように表示用画像を逐次生成してもよい。

上記構成例によれば、自身が進行させているゲームの状況に加えて、対戦相手のゲーム状況もユーザに提示できる。

他の構成例として、画像生成手段は、表示用画像の中央に位置する第１領域に第１画像を配置し、当該第１領域とは異なる位置となる第２領域に第２画像のそれぞれを配置するように表示用画像を逐次生成してもよい。

上記構成例によれば、ユーザが進行させているゲームの状況を、対戦相手が進行させているゲームの状況と判別しやすい態様でユーザに提示できる。

他の構成例として、画像生成手段は、表示用画像の中央に位置する第１領域に第１画像
を配置し、当該第１領域の左右となる位置に第２領域を１つずつ配置し、左右それぞれの第２領域に第２画像のそれぞれを配置するように表示用画像を逐次生成してもよい。

上記構成例によれば、ユーザ自身が進行させているゲームにかかるゲーム画像を中央に表示できる。そして、その左右それぞれに対戦相手のゲーム状況を示す画像を表示できる。これにより、自身のゲーム画像と対戦相手のゲーム状況を示す画像との間の視線の移動を最小限に抑えることができる。

他の構成例として、画像生成手段は、標的として特定した対戦相手のゲームのプレイ状況を示す状況データに基づいて生成される第２画像に標的用画像を重畳した表示用画像（１６１）を逐次生成するようにしてもよい。

上記構成例によれば、ユーザ自身が現在標的としている対戦相手を把握させやすくすることができる。

他の構成例として、対戦ゲームは、所定のプレイフィールド内において時間経過に応じて増加するパズルオブジェクトを消去するパズルゲームであってもよい。更に、変化指示手段は、特定手段によって標的として特定された対戦相手のパズルオブジェクトの数を増加させるための指示を行ってもよい。そして、ゲームプログラムは、パズルオブジェクトのプレイフィールド内での配置状態が予め定義されている敗北条件を満たした場合、当該ゲームの続行ができないゲーム状況であると判定し、ユーザおよび複数の対戦相手の全員の中で最後まで当該敗北条件を満たさずに残った場合に勝利条件を満たしたと判定する勝敗判定手段としてコンピュータを更に機能させる構成であってもよい。

上記構成例によれば、ユーザ自身のゲームを進行させながら適宜対戦相手のゲーム状況を変化させる指示を行い、敗北条件を満たさずに最後までプレイし続けることを目的とする対戦パズルゲームをユーザに提供できる。

他の構成例として、ゲームプログラムは、前記ユーザが標的として特定している対戦相手にかかるゲーム状況が、当該ユーザの情報処理装置の変化指示手段が行った指示によって増加したパズルオブジェクトが原因となって敗北条件を満たした場合に、当該ユーザに関連づけられた敗北誘導数に所定値を加算する加算手段としてコンピュータを更に機能させてもよい。更に、状況データには、対戦相手の敗北誘導数を示す敗北誘導数情報が含まれていてもよく、画像生成手段は、敗北誘導数情報に基づいて、対戦相手の有する敗北誘導数を示す情報が含まれる第２画像を生成するようにしてもよい。

上記構成例によれば、多くの対戦相手を敗北に導いたユーザが誰であるかを把握させやすくすることができる。

他の構成例として、加算手段は、ユーザに関連づけられた敗北誘導数に所定値を加算するとき、敗北条件を満たした対戦相手が所持する敗北誘導数を加えた値を所定値として加算してもよい。

上記構成例によれば、対戦ゲームの戦略性を高め、ゲームの興趣性を高めることができる。

他の構成例として、特定手段は、方針選択手段によって選択されている方針が第１の方針の場合、敗北誘導数が最も大きい対戦相手を標的として特定してもよい。

上記構成例によれば、敗北誘導数が多いユーザを標的とすることで、敗北誘導数を稼ぎ
やすくすることができる。

他の構成例として、特定手段は、方針選択手段によって選択された方針が第２の方針の場合、被特定情報データに基づき、前記ユーザを標的として特定している対戦相手を当該ユーザの標的として特定してもよい。

上記構成例によれば、自分を標的として設定している対戦相手を自身の標的として設定できる。これにより、多数の対戦相手から標的として狙われている場合、これらの対戦相手を標的として選択する操作を簡易なものにできる。また、ユーザにとって一方的に不利な状況になることを防ぎ、ゲームバランスを適度なものにすることができる。

本実施形態によれば、多数の対戦相手から所定の対戦相手を選択したい場合に、ユーザの意思を反映した速やかな選択操作を行うことができる。

本実施形態に係る情報処理システムの全体像を示す模式図 ゲームシステムの外観図 本体装置２の内部構成の一例を示すブロック図 サーバ１０１の内部構成の一例を示すブロック図 本実施形態に係るゲーム画像の一例 第１領域１５１を拡大した図 本実施形態に係るゲーム画像の一例 本実施形態に係るゲーム画像の一例 第１領域１５１を拡大した図 第１領域１５１を拡大した図 第１領域１５１を拡大した図 第１領域１５１を拡大した図 本実施形態に係るゲーム画像の一例 図１３の第２領域１５２Ｌを拡大した図 本実施形態に係るゲーム画像の一例 本実施形態に係るゲーム画像の一例 本実施形態に係るゲーム画像の一例 本実施形態に係るゲーム画像の一例 本実施形態に係るゲーム画像の一例 本体装置２の記憶部８４に記憶される各種データの一例を示すメモリマップ サーバ送信用データ３０５の構成の一例 更新用データ３０６のデータ構成の一例 対戦相手データ３０７の構成の一例 待機ブロックデータ３０９のデータ構成の一例 サーバ１０１の記憶部１１２に記憶される各種データの一例を示すメモリマップ サーバ１０１および各ゲームシステム１との協働による全体的な処理の流れを示す図 本ゲーム処理の詳細を示すフローチャート 本ゲーム処理の詳細を示すフローチャート 本ゲーム処理の詳細を示すフローチャート ブロック消去関連処理の詳細を示すフローチャート お邪魔ブロック処理の詳細を示すフローチャート ゲームオーバー処理の詳細を示すフローチャート サーバ処理の詳細を示すフローチャート

以下、本発明の一実施形態について説明する。図１は、本実施形態に係る情報処理システムの全体像を示す模式図である。本実施形態の情報処理システム１００は、サーバ１０１と、複数のゲームシステム１とを含んでいる。サーバ１０１と、各ゲームシステム１とは、インターネット１０３を介して通信可能に構成されている。

上記のような構成で実行される情報処理の一例として、本実施形態では、ゲーム処理を例として説明する。具体的には、各ゲームシステム１において単独のユーザの操作に基づいて他のゲームシステム１とは独立して進行するゲーム処理が実行されつつ、サーバ１０１を介してゲームシステム１間で当該ゲーム処理に基づく所定のデータを送受信することで、多人数参加型の対戦型ゲームを実現するゲーム処理が実行される。

次に、本実施形態にかかるゲームシステム１について説明する。このゲームシステムはどのようなものでもよいが、図２に、一例として本例で用いるゲームシステムの外観図を示す。図２で示すゲームシステム１は、本体装置（情報処理装置；本実施形態ではゲーム装置本体として機能する）２と左コントローラ３および右コントローラ４とを含む。本体装置２は、左コントローラ３および右コントローラ４がそれぞれ着脱可能である。つまり、ゲームシステム１は、左コントローラ３および右コントローラ４をそれぞれ本体装置２に装着して一体化された装置として利用できる。また、ゲームシステム１は、本体装置２と左コントローラ３および右コントローラ４とを別体として利用することもできる。なお、図２は、本体装置２に左コントローラ３および右コントローラ４を装着した状態の一例を示す図である。図２に示すように、左コントローラ３および右コントローラ４は、それぞれ本体装置２に装着されて一体化されている。本体装置２は、ゲームシステム１における各種の処理（例えば、ゲーム処理）を実行する装置である。本体装置２は、ディスプレイ１２を備える。左コントローラ３および右コントローラ４は、ユーザが入力を行うための操作部を備える装置である。

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

本体装置２は、ネットワーク通信部８２を備える。ネットワーク通信部８２は、プロセッサ８１に接続される。ネットワーク通信部８２は、ネットワークを介して外部の装置と通信（具体的には、無線通信）を行う。本実施形態においては、ネットワーク通信部８２は、第１の通信態様としてＷｉ−Ｆｉの規格に準拠した方式により、無線ＬＡＮに接続して外部装置と通信を行う。また、ネットワーク通信部８２は、第２の通信態様として所定の通信方式（例えば、独自プロトコルによる通信や、赤外線通信）により、同種の他の本体装置２との間で無線通信を行う。なお、上記第２の通信態様による無線通信は、閉ざされたローカルネットワークエリア内に配置された他の本体装置２との間で無線通信可能であり、複数の本体装置２の間で直接通信することによってデータが送受信される、いわゆ
る「ローカル通信」を可能とする機能を実現する。

本体装置２は、コントローラ通信部８３を備える。コントローラ通信部８３は、プロセッサ８１に接続される。コントローラ通信部８３は、本体装置２と左コントローラ３および右コントローラ４とを別体として利用する場合において、左コントローラ３および／または右コントローラ４と無線通信を行う。本体装置２と左コントローラ３および右コントローラ４との通信方式は任意であるが、本実施形態においては、コントローラ通信部８３は、左コントローラ３との間および右コントローラ４との間で、Ｂｌｕｅｔｏｏｔｈ（登録商標）の規格に従った通信を行う。

また、本体装置２は、本体装置２が左コントローラ３と有線通信を行うための端子である左側端子１７と、本体装置２が右コントローラ４と有線通信を行うための右側端子２１を備える。

また、ディスプレイ１２は、プロセッサ８１に接続される。プロセッサ８１は、（例えば、上記の情報処理の実行によって）生成した画像および／または外部から取得した画像をディスプレイ１２に表示する。

本体装置２は、コーデック回路８７およびスピーカ（具体的には、左スピーカおよび右スピーカ）８８を備える。コーデック回路８７は、スピーカ８８および音声入出力端子２５に接続されるとともに、プロセッサ８１に接続される。コーデック回路８７は、スピーカ８８および音声入出力端子２５に対する音声データの入出力を制御する回路である。

なお、図示は省略するが、本体装置２で生成された画像や音声については、所定の出力端子を介して、外部モニタ／外部スピーカに出力することも可能である。

［コントローラについて］
また、図示は省略するが、左コントローラ３、右コントローラ４は、それぞれ、本体装置２との間で通信を行う通信制御部を備えている。本体装置２に左コントローラ３および右コントローラ４を装着した状態では、上記左側端子１７および右側端子２１を介した有線通信が可能である。また、本体装置２と左コントローラ３および右コントローラ４とを別体として利用する場合は、上記端子を介さない無線通信で本体装置２と通信を行うことが可能である。通信制御部は、コントローラの各入力部から、入力に関する情報（具体的には、操作に関する情報を取得する。そして、通信制御部は、取得した情報（または取得した情報に所定の加工を行った情報）を含む操作データを本体装置２へ送信する。なお、操作データは、所定時間に１回の割合で繰り返し送信される。なお、入力に関する情報が本体装置２へ送信される間隔は、各入力部について同じであってもよいし、同じでなくてもよい。

［サーバのハードウェア構成］
次に、上記サーバ１０１の構成について説明する。図４は、サーバ１０１の内部構成の一例を示すブロック図である。サーバ１０１は、プロセッサ１１１と、記憶部１１２と、通信部１１３とを少なくとも備えている。プロセッサ１１１は、サーバ１０１を制御するための各種プログラムを実行する。記憶部１１２には、プロセッサ１１１によって実行される各種プログラムおよび利用される各種データが格納される。通信部１１３は、有線、または無線通信によってインターネット１０３と接続し、上記ゲームシステム１との間で所定のデータを送受信する。

［ゲーム処理の概要］
次に、本実施形態で実行されるゲーム処理の概要について説明する。本実施形態では、
ゲーム処理の一例として、時間経過に応じて増加する「パズルオブジェクト」を消去するパズルゲーム処理が実行される。具体的には、本実施形態では、２次元のプレイフィールドにおいて、上から時間経過に応じて１つずつ落下してくるパズルオブジェクトを移動・回転させて積み上げていき、所定の条件を満たすことで当該積み上げたパズルオブジェクトの少なくとも一部を消去するというアクションパズルゲーム処理が実行される（「落ちものパズル」とも呼ばれるゲーム処理である）。当該パズルオブジェクトとしては、例えば格子状のブロックや、カプセル形状のピースや、所定の形状のパネル等である。また、当該所定の条件としては、例えば、横１行を全てブロックで埋めること、同じ色のパネルを所定方向に所定数以上揃えること、同じ柄のパネルを所定数以上揃えること、同じ形状のピースを所定数以上揃えること、同色のブロックで所定の形状（正方形など）を作ること、等である。本実施形態では、プレイフィールドとして、縦２０×横１０マス分のプレイフィールドを想定し、パズルオブジェクトとして様々な形状を構成しているブロック群が落下するものを例とする。また、所定条件として、プレイフィールドの横１行分がブロックで埋まると、そのブロックが消去される場合を例として説明する。例えば、各ユーザは、当該プレイフィールド１５１１の上部から落下してくるブロック群を左右方向、あるいは下方向に移動させ、また、当該ブロック群を回転させる操作を行う。そして、プレイフィールドの最下段または既に積み上がっている他のブロックの上に落下させることで、当該ブロックの位置を固定できる。その結果、横１行分がブロックで埋まっていれば、当該横１行分のブロックが消去される。また、プレイフィールドの最上段までブロックが積み上がると、ゲームオーバーとなる。

また、本実施形態にかかるパズルゲーム処理として、最大で９９人のユーザで対戦できるゲーム処理を想定する。この対戦の概要について説明する。まず、当該対戦の勝利条件としては、「９９人の中でゲームオーバーにならないまま最後まで残る」ことである。そして、本ゲームでは、各ユーザが個々にパズルゲームを進行させつつ、所定の他のユーザに後述する「お邪魔ブロック」を送り込むことでゲーム進行を妨害できる。このように、ユーザは、他のユーザのゲーム進行の妨害を試みながら各自のパズルゲームを進行させ、ゲームオーバーにならずに最後までプレイし続けることを目指すものである。なお、以下の説明では、このような他のユーザに「お邪魔ブロック」を送り込むことを、他のユーザへの「攻撃」と呼ぶ。

より具体的に説明すると、各ゲームシステム１のディスプレイ１２には、表示用画像の一例である、図５に示すようなゲーム画像がそれぞれ表示される。当該ゲーム画像の構成要素の詳細は後述するが、各ユーザは、後述のプレイフィールド１５１１に対してパズルゲームに係る操作を行い、ユーザ毎に個別にパズルゲーム処理を進行させていく。換言すれば、基本的には、各ユーザにかかるプレイフィールドに対しては、各ユーザが各自のコントローラを操作することで生成された操作データの内容のみが反映される。つまり、他のユーザが操作したコントローラにかかる操作データが直接的に反映されるようなオブジェクト等はプレイフィールド内に存在しない。例えば、対戦格闘ゲームやレースゲームのような、同じステージや同じゲームフィールド内に複数のユーザがそれぞれ操作するキャラクタ等が存在し、各ユーザの操作が反映されるという対戦ゲームではないということである。そして、本ゲームでは、上記ブロックを消去したときに、そのときに「標的」として設定されている他のユーザに対して、上記の「お邪魔ブロック」と呼ばれる特殊なブロックを送り込むことで、他のユーザを攻撃できる。また、逆に他のユーザから「お邪魔ブロック」を送り込まれることもあり得る。つまり、他のユーザから攻撃を受けることもあり得る。そして、本実施形態では、当該「お邪魔ブロック」に関するデータや各ユーザのプレイフィールド状況を示すデータを他のユーザ間と送受信する。これにより、各ゲームシステム１において個別にパズルゲームを進行させながら、上記送受信されるデータに基づいて、他のユーザのプレイフィールドの状況等を反映した画像も表示し、他のユーザの状況も把握できるようにしている。また、ユーザ間で行われる「攻撃」も反映させている
。つまり、各ゲームシステム１で独立してパズルゲーム処理を進行させながらも、上記送受信されるデータを用いてゲームシステム１間でゲーム処理を連動させることで、本実施形態にかかる対戦ゲーム処理を実現している。

［ゲーム画像例］
次に、本パズルゲーム処理におけるゲーム画像の構成要素、およびそれに伴うユーザの操作やギミックに関して説明する。図５は、各ゲームシステム１のディスプレイ１２に表示される本パズルゲームのゲーム画像の一例である。図５では、第１領域１５１と、第２領域１５２Ｌ、第２領域１５２Ｒ（以下では総称して第２領域１５２と呼ぶこともある）とが示されている。第１領域１５１は、ゲーム画像の略中央に配置されており、その左側に第２領域１５２Ｌが配置されている。また、第１領域１５１の右側に第２領域１５２Ｒが配置されている。第１領域１５１には、主に当該ゲームシステム１のユーザの操作によって進行するパズルゲームに関する各種画像が表示される。第２領域１５２Ｌ、１５２Ｒには、他のユーザがプレイしているパズルゲームのプレイフィールドの状況を示す画像が表示される。なお、以下の説明では、当該他のユーザのことを「対戦相手」と呼ぶ。

次に、第１領域１５１の詳細について説明する。図６は、上記第１領域１５１を拡大して示した図である。図６において、第１領域１５１には、プレイフィールド１５１１、待機ブロック領域１５１２、ネクストブロック領域１５１３、バッジ表示領域１５１４が表示される。また、プレイフィールド１５１１の上端付近には、作戦操作パネル１５１５も表示されている。

プレイフィールド１５１１は、横１０マス×縦２０マスからなる２次元のフィールドであり、本パズルゲームのメインとなる部分でもある。当該プレイフィールド１５１１の上方から上記ブロック群が下方に向かって落下する。上記のようにユーザはプレイフィールド１５１１内で当該ブロック群を左右に移動させたり、回転させたりする操作ができる。そして、積み上げた横１行分が埋まったブロックを消去することができる。なお、図６では各マス目を点線で区切って示しているが、実際のゲーム画像では、このようなマス目を示す線は表示されていてもよいし、表示されなくてもよい。

次に、待機ブロック領域１５１２は、対戦相手から送り込まれた「お邪魔ブロック」に関する情報を表示するための領域である。この領域の表示内容に関しては、後ほど「お邪魔ブロック」の説明と併せて説明する。

ネクストブロック領域１５１３は、今後落下予定のブロック群について提示するための領域である。なお、本ゲームにおいては、様々な形状のブロックが１つずつ落下してくるが、これらブロックが落下する順番については、９９人のユーザ全てについて同じ順番であるものとする。

バッジ表示領域１５１４は、当該ユーザが獲得した「バッジ」を表示するための領域である。当該「バッジ」は、当該ユーザが送り込んだ「お邪魔ブロック」が原因でゲームオーバーになった対戦相手の数（いわば、当該ユーザがとどめをさした対戦相手の数）を示すものである。当該「バッジ」の詳細については後述する。

作戦操作パネル１５１５は、「作戦」を選択するための操作パネルである。詳細は後述するが、「作戦」とは、攻撃対象とする（お邪魔ブロックを送り込む）対戦相手（以下、標的と呼ぶ）の選択方針の一例である。プロセッサ８１は、そのときに選択されている作戦に基づいて、９８人の対戦相手の中から所定のユーザを「標的」として設定する。なお、本実施形態では、当該作戦の選択操作として、右コントローラ４が備えるアナログスティックを用いる。当該アナログスティックを上下左右方向に傾けることで、各方向に対応
した４つの作戦のうちの１つが選択されるものとする。図６では、作戦操作パネル１５１５の略中央にアナログスティックを模した円の画像が表示され、その上下左右となる方向にそれぞれ、作戦名を示す選択肢画像が表示されている。このような構成で、ユーザのパズルゲーム操作（ブロックの移動や回転操作）を極力邪魔することなく、作戦の選択操作を速やかに行うことが可能となっている。

次に、図５で示した第２領域１５２Ｌおよび１５２Ｒについて説明する。上記のように、第２領域１５２Ｌは第１領域１５１の左側に配置され、第２領域１５２Ｒは第１領域１５１の右側に配置されている。第２領域１５２Ｌには、９８人の対戦相手のうちの４９人分の対戦相手のプレイフィールドの状況を示す４９個の対戦相手画像１５２１が、７×７の配列で表示される。また、第２領域１５２Ｒには、残り４９人分の対戦相手のプレイフィールド１５１１の状況を示す４９個の対戦相手画像１５２１が、同様に７×７の配列で表示される。

［攻撃について］
次に、対戦相手に対する攻撃、すなわち、「お邪魔ブロック」の送り込みに関して説明する。この「お邪魔ブロック」は、対戦相手のプレイフィールドの状況に変化を及ぼす要素の一例である。以下に説明するような「お邪魔ブロック」の送り込みによって、戦術性の高い対戦ゲームを提供することができる。

まず、自分が対戦相手に対して攻撃する場合に関して説明する。本ゲームでは、まず、「お邪魔ブロック」を送り込む相手、すなわち、上記「標的」を決める必要がある。この「標的」は、後述する「作戦」に応じてプロセッサ８１が設定するが、原則として、「標的」として設定できる相手は１人だけである。但し、後述する「作戦」のうちの「カウンター狙い」の場合は、複数の対戦相手を「標的」として設定可能である。そして、「標的」として設定された対戦相手にかかる対戦相手画像１５２１には、図７に示すように、これに重畳するようにして標的画像１６１が表示される。これにより、そのユーザを「標的」としているのかをユーザに把握させやすくすることができる。

次に、自分が他のユーザの「標的」にされている場合のゲーム画像の表示に関して説明する。この場合は、図８に示すように、プレイフィールド１５１１の下部に「ＣＡＵＴＩＯＮ」パネル１６２が表示される。さらに、自分を「標的」としている対戦相手にかかる対戦相手画像１５２１（の中点）と当該「ＣＡＵＴＩＯＮ」パネル１６２とを結ぶ直線１６３も表示される。また、自分を「標的」としている対戦相手にかかる対戦相手画像１５２１についても、太枠で囲まれたような表示態様に変化している。このような表示を行うことで、特に本実施形態で想定するような多数の対戦相手が存在するゲームにおいて、自分が対戦相手の「標的」にされている場合に、どのユーザが自分を「標的」としているのか、何人の対戦相手から「標的」とされているのか、等を容易に把握することが可能となる。なお、このような「標的」にされていることを示す手法については、本例のような「ＣＡＵＴＩＯＮ」パネル１６２と直線１６３とを利用した画像の表示に限るものではない。対戦相手がユーザを「標的」として特定していることを判別可能とする目的が達成できるのであれば、どのような画像や表示態様を用いてもよい。

なお、上記標的とする対戦相手や、標的にされている対戦相手については、後述の「作戦」に応じて刻々と変化する。そのため、特に「作戦」を変更しなくても、標的画像１６１や上記直線１６３の表示位置は刻々と変化し得る。

上記のように、「標的」を設定した状態で、ユーザがブロックを消去した場合、その消去した内容（具体的には消去した行数）に応じた「お邪魔ブロック」を「標的」としている対戦相手に送り込むことができる。また、逆に、自分を「標的」としている対戦相手か
ら「お邪魔ブロック」が送り込まれることもある。以下、他のユーザから「お邪魔ブロック」を送り込まれた場合の動作に関して図９〜図１２を用いて説明する。

図９は、第１領域１５１を拡大した図である。この図では、プレイフィールド１５１１に、縦２×横９のブロック群１７２が積み上がっている状態を示す。また、待機ブロック領域１５１２には、１つのブロック画像１７１が表示されている。このブロック画像１７１は、対戦相手から送り込まれたお邪魔ブロックを示す画像である。本ゲームでは、対戦相手からお邪魔ブロックが送り込まれた場合、一旦待機ブロック領域１５１２に上記ブロック画像１７１が表示される。その後、所定の待機時間だけ待機した後に、プレイフィールドに当該ブロック画像１７１に対応するお邪魔ブロックがプレイフィールド１５１１の下方から出現する（せり上がってくる）。以下の説明では、上記待機中のお邪魔ブロックのことを「待機中ブロック」と呼び、上記ブロック画像１７１は「待機ブロック画像」と呼ぶ。

次に、図１０は、上記待機時間が経過して、お邪魔ブロック１７３がプレイフィールド１５１１に出現した状態を示す図である。図１０では、プレイフィールド１５１１の一番下の行に、左から４マス目を除いた９マスを埋めているお邪魔ブロック１７３が表示されている。ここで、本実施形態では、お邪魔ブロック１７３の内容として、横１行分のうちいずれか１マスだけランダムで空白にした９個分のブロックがお邪魔ブロック１７３として生成されるものとする。また、お邪魔ブロック１７３の出現に伴って、対応する待機ブロック画像１７１は待機ブロック領域１５１２から消去される。

ここで、待機ブロック領域１５１２に表示される待機ブロック画像１７１の個数は、出現するお邪魔ブロック１７３の行数に対応する。図９および図１０の例では、待機ブロック画像１７１は１個だけであったため、お邪魔ブロック１７３も１行分だけ出現している。この点、例えば、図１１に示すように、待機ブロック画像１７１が３個表示されている場合は、図１２に示すように、３行分のお邪魔ブロック１７３が出現する。

［相殺について］
次に、お邪魔ブロックの「相殺」について説明する。上記のように待機ブロック領域１５１２に待機ブロック画像１７１が表示されている間にユーザがプレイフィールド１５１１内でブロックを消去することで、その消去した行数に応じて待機中ブロック画像１７１を消去することができる。つまり、待機中ブロックが存在している場合、ユーザがブロックを消去することで、当該待機中ブロックを相殺できる。例えば、待機ブロックが１個存在する場合に、ユーザが３行分のブロックを消去した場合、消去した３行分のうち１行分と当該１個の待機ブロックとが相殺される。その結果、当該待機ブロックはなくなる。また、そのときにユーザが「標的」にしている他ユーザに対しては、残り２行分の消去に基づいてお邪魔ブロックの送り込みが行われる。また、別の例として、待機ブロックが５個存在しており、ユーザが３行分のブロックを消去した場合は、この３行分の消去で３個の待機中ブロックが相殺される。その結果、待機中ブロックの数が２個となる。このように、自分に送り込まれたお邪魔ブロックを出現させないようにすることを可能とすることで、ゲームの戦略性を高めている。

［バッジについて］
次に、対戦相手を敗北に誘導した数を示す情報を示す構成の一例である、上記「バッジ」に関して説明する。本ゲームでは、ゲームフィールドの上端までブロックが積み上がるとゲームオーバーとなる。そして、上記お邪魔ブロックはゲームフィールドの下方からせり上がるようにして出現する。そのため、お邪魔ブロックの出現が契機となってブロックがゲームフィールドの上端まで到達し、ゲームオーバーとなることもあり得る。本ゲームでは、ユーザが「標的」に送り込んだお邪魔ブロックの出現によってその「標的」がゲー
ムオーバーになった場合、バッジを一つ獲得できる。換言すれば、自分の攻撃によって「標的」にとどめをさした場合に、バッジを一つ獲得できる。また、当該バッジは、対戦相手を敗北に誘導した数を示す情報であるともいえる。このようにして獲得したバッジの数を示す情報は上記バッジ表示領域１５１４に表示される。図１３は、バッジに関する情報を示しているゲーム画像の一例である。図１３では、バッジ表示領域１５１４に３つのバッジ画像１８１が表示されている。つまり、ユーザは３つのバッジを獲得していることが示されている。なお、他の実施形態では、対戦相手を敗北に誘導した数を示す情報として、本例のようなバッジ以外の構成を用いてもよい。

また、本ゲームでは、他ユーザが所持しているバッジ数の情報も対戦相手画像１５２１において表示される。上記図１３における第２領域１５２Ｌを拡大したものを図１４として示す。図１４では、対戦相手画像１５２１Ａにおいて、左上端付近に１つのバッジ画像１８１が表示されている、また、対戦相手画像１５２１Ｂでは、左上端付近に２つのバッジ画像１８１が表示されている。これは、対戦相手画像１５２１Ａにかかるユーザはバッジを１つ所持していることを示し、対戦相手画像１５２１Ｂにかかるユーザはバッジを２つ所持していることを示している。そして、このように、既にバッジを所持している対戦相手をゲームオーバーに追い込んだ場合は、上記のようにバッジを１つ獲得すると共に、当該相手が所持しているバッジをも獲得することができる。例えば２つのバッジを所持している対戦相手をゲームオーバーに追い込んだ場合は、１＋２個の、合計３個のバッジを獲得できる。

また、本ゲームでは、バッジの所持数に応じて、出現させる上記お邪魔ブロック１７３の行数を変化させることができる。以下では、出現させるお邪魔ブロック１７３の行数（換言すれば、上記待機ブロック数）のことを「攻撃力」と呼ぶ。本例では、例えば、攻撃力が”１”で、１行のお邪魔ブロック１７３を出現させることができるものとする。そして、ユーザが実際に消去した行数に応じた攻撃力（以下では基礎攻撃力と呼ぶ）に、バッジの所持数に応じた攻撃力が加算されることで、最終的に対戦相手のプレイフィールド１５１１に出現させるお邪魔ブロック１７３の行数が決まる。一例として、ユーザが１行分のブロックを消去した場合を想定する。この場合、基礎攻撃力は”１”である。このような場合で、このような場合で、バッジを１〜２個所持しているときは、攻撃力が”１”加算され、最終的な攻撃力としては”２”となる。その結果、対戦相手のプレイフィールドには２行分のお邪魔ブロック１７３を出現させることができる。また、例えば、バッジを３〜４個所持しているときは、攻撃力が”２”加算され、最終的な攻撃力としては”３”となる。また、例えばバッジを５〜６個所持しているときは、攻撃力が”３”加算され、最終的な攻撃力としては”４”となる。このように、バッジを多く所持していれば「攻撃力」を高めることができ、「バッジの奪い合い」という要素を導入してゲームの興趣性を高めることができる。

［ピンチ状態について］
ところで、本ゲームでは、積み上がったブロックがプレイフィールド１５１１の上５行分のマスのいずれかに到達した場合、ゲームオーバーになる危険性が高い状態とである「ピンチ状態」として扱われる。ユーザが「ピンチ状態」になった場合は、例えばプレイフィールド１５１１を赤枠で囲む等、ピンチ状態であることを示すような表示態様の変化が行われる。また、対戦相手が「ピンチ状態」になった場合は、例えばそのユーザに係る対戦相手画像１５２１を点滅表示させる等、そのユーザが「ピンチ状態」であることを示すように対戦相手画像１５２１の表示態様を変化させる。「ピンチ状態」にある対戦相手の存在をユーザに把握させやすくすることができる。また、自分が「ピンチ状態」であることを認識させやすくすることができる。

［作戦について］
次に、上述した作戦に関して説明する。本ゲームにおいて、作戦は、ゲームオーバーとなっていない対戦相手の中から「標的」を決定する方針として用いられる。まず、当該作戦の意義について説明する。本ゲームは、９９人という大人数で対戦するものであり、自分以外に９８人もの対戦相手が存在する状態となる。また、本ゲームでは上記のように「標的」を選択する必要性がある。この「標的」の選択方法として、例えば上記第２領域１５２に表示される合計９８個の対戦相手画像の中から任意の１つをユーザが直接的に選択する操作を行わせる、ということも考えられる。例えば選択用のカーソルを移動させたり、タッチパネル画面を用いている場合であればタッチ操作を行わせたりする、等である。しかし、本ゲームのようなアクションパズルゲームでは、その操作にある程度リアルタイム性が求められるため、落下するブロックの操作と並行してこのような多数の中から「標的」とする相手を吟味し、選択する操作を行うことは困難であると考えられる。そこで、本実施形態では、「標的」を選択するための方針である作戦をユーザに提示し、パズルゲームの操作と併用可能な簡易な操作でこの作戦が選択可能なように構成している。そして、実際の「標的」の選択については、選択中の作戦に基づいてプロセッサ８１が所定の対戦相手を選択し、「標的」として設定する処理を実行する。

次に、本ゲームで定義されている作戦の例を示す。本ゲームでは、以下の４つの作戦が選択可能なようにユーザに提示される。なお、これらの作戦名を示す文字列は、図６で示した上記作戦操作パネル１５１５の上記選択肢画像において表示されているものとする。
作戦１：とどめ狙い
作戦２：ランダム
作戦３：バッジ狙い
作戦４：カウンター
以下、各作戦について説明する。

［作戦１：とどめ狙い］
この作戦は、上記「ピンチ状態」となっている対戦相手を「標的」とする方針の作戦である。ユーザがこの作戦を選択すると、「ピンチ状態」の対戦相手が「標的」として選択される。つまり、ゲームオーバーに追い込みやすそうな対戦相手を狙う作戦といえる。「ピンチ状態」の対戦相手が複数いる場合は、例えば一番多くブロックが積み上がっている対戦相手が「標的」として選択されてもよい。あるいは、「ピンチ状態」の複数の対戦相手の中から１人をランダム選択するようにしてもよい。

［作戦２：ランダム］
この作戦は、ゲームオーバーとなっていない対戦相手の中から１人のユーザをランダムで選択して「標的」に設定する作戦である。本ゲームでは、ゲーム開始直後はこの作戦がデフォルトで選択されているものとする。

［作戦３：バッジ狙い］
この作戦は、ゲームオーバーとなっていない対戦相手の中で、最も多く上記バッジを所持している対戦相手を「標的」に設定する作戦である。図１５に、当該「バッジ狙い」作戦を選択している場合のゲーム画像例を示す。図１５では、この時点で最もバッジを多く所持している対戦相手画像１５２１Ｂに標的画像１６１が重畳表示されている。つまり、対戦相手画像１５２１Ｂにかかる対戦相手を「標的」としている状態である。上述のように、自分がとどめを刺した場合、その「標的」が所持するバッジも獲得できる。そして、バッジを多く所持していれば、お邪魔ブロック１７３を送り込むときの「攻撃力」を高めることができるため、バッジの数を積極的に増やしたい場合に有効な作戦といえる。

［作戦４：カウンター］
この作戦は、自分を「標的」にしている対戦相手を「標的」として設定する作戦である
。また。自分を「標的」にしている対戦相手が複数いれば、その全員を「標的」として設定する。上記のように、本ゲームでは「標的」は原則として１人ではあるが、当該「カウンター」作戦については、複数の「標的」を設定可能となっている。図１６に、当該「カウンター」作戦を選択している場合のゲーム画像例を示す。図１６では、４人の対戦相手から自分が「標的」に設定されている状態である。そして、「カウンター」作戦によって、これら４人の対戦相手を「標的」として設定し、それぞれに対応する対戦相手画像１５２１に標的画像１６１を重畳表示している状態となっている。また、「カウンター」作戦を選択している状態において、自分を「標的」とする対戦相手の数が変動すれば、それに伴って、「標的」とする相手および標的画像１６１の表示位置も適宜変更されることになる。

また、「カウンター」作戦を選択している場合、上記バッジ数に応じた攻撃力の変化とは別に、自分を「標的」にしている対戦相手の数に応じて攻撃力を変化させるようにしてもよい。例えば、自分を「標的」としている対戦相手数が多いほど、これらの対戦相手にお邪魔ブロックを送り込むときの攻撃力が更に高くなるようにしてもよい。一例を挙げると、上記基礎攻撃力が”１”でバッジの所持数が０個の場合を想定する。この場合、「カウンター」作戦の要素を考慮しなければ、最終的な攻撃力は”１”となる。このような場合で、「カウンター」作戦を選択し、自分を「標的」に設定している（＝自分が「標的」にも設定しかえしている）対戦相手が１〜３人であれば、例えば攻撃力に更に”１”が加算され、「カウンター」作戦における最終的な攻撃力は”２”となる。また、当該対戦相手が４〜６人であれば、例えば攻撃力に更に”２”が加算され、「カウンター」作戦における最終的な攻撃力は”３”となる。また、例えば基礎攻撃力が”１”、バッジによる加算値が”１”である場合、「カウンター」作戦中の「標的」数が１〜３人であれば、最終的な攻撃力は”３”となり、「標的」数が４〜６人であれば、最終的な攻撃力は”４”となる。つまり、バッジ所持数に基づく攻撃力加算とは別枠で、「カウンター」作戦による攻撃力の加算が行われる。これにより、より多くの対戦相手から狙われているほど自分の攻撃力を高めて反撃することができ、ゲームの興趣性を高めることができる。特に、バッジの所持数が多い場合、より多くの対戦相手から狙われやすくなる可能性が高くなる。この場合に、「カウンター」作戦を選択しておくことで、一度に多数の対戦相手に対して、よりたくさんのお邪魔ブロックを送り込むことができ、一方的に不利な展開とはならないようにしてゲームの興趣性を高めることができる。

なお、「作戦」については上記に限るものではなく、他の実施形態では、例えば以下のような「作戦」を選択可能なようにユーザに提示するようにしてもよい。
［出る杭討ち］：自分に対する攻撃頻度の高い対戦相手を優先して「標的」とする。
［タイマン討ち］：同じく「タイマン討ち」を選択している対戦相手とどちらかがゲームオーバーになるまで、１対１で勝負する。この場合、他の対戦相手からの攻撃は受けない状態となる。
［ピンポイント討ち］：ランダムで選択された１人の対戦相手を固定的に「標的」とする。つまり、この作戦を選択している間は、「標的」が１人に固定される。
［鉄壁ガード］：ブロックを消去した際、お邪魔ブロック１７３の送りこみは行わずに、上述した「相殺」に用いるためにストックしておく作戦。

なお、他の実施形態では、上記のような「作戦」の指定によって標的を設定する操作方法と、ユーザが直接的に「標的」を指定する操作方法（例えば９９個の対戦相手画像１５２１のうちの一つをユーザがタップしたり、カーソルを合わせて所定のボタンを押したりする等）とを併用可能なように構成してもよい。これにより、「作戦」（「標的」を決定する方針）を選択操作で半自動的に「標的」を決定できることに加え、ユーザが直接「標的」とする対戦相手を決定することもできるため、「標的」の決定に関して、よりユーザの意思を反映させやすくすることができる。

［ゲームオーバー後にユーザができることについて］
次に、ゲームオーバーとなった場合の処理に関して説明する。本ゲームでは、各ユーザがゲームオーバーになった場合、ゲームを終了してゲーム画像の表示を終わらせることもできるが、対戦相手同士の対戦を「観戦」することも可能である。例えば、ゲームオーバーになったときに、ユーザに対して、この後観戦するか否かの問い合わせが行われる。これに対してユーザが観戦することを選べば、今回プレイした対戦ゲームが終了するまで（最後の１人が確定するまで）、ゲーム画像は表示され続ける。すなわち、ゲームオーバー後も、対戦相手のゲーム状況を示すデータをサーバ１０１から取得し続ける。この場合、第１領域１５１の表示内容については、ゲームオーバー時の内容が表示されたままとなり、第２領域１５２については、その後の対戦ゲームの状況に応じてその表示内容が変化することになる。なお、このようにゲームオーバー後に観戦している状態のことを「観戦モード」と呼ぶ。

ここで、図１７および図１８を用いて、対戦相手がゲームオーバーになった後の第２領域１５２の表示に関して説明する。図１７は、第２領域１５２Ｌの一番左上の対戦相手画像１５２１Ａにかかる対戦相手が最初にゲームオーバーになった状態を示す図である。図１７では、対戦相手画像１５２１Ａとして、「ＫＯ」の文字を含む画像（ゲームオーバーとなったことを示す画像）と、その下に順位を示す数値とが表示されている。この図では、９９人対戦において最初にゲームオーバーとなったため、「９９位」が確定したことを示している。

次に、図１８は、図１７の状態の後に、第２領域１５２Ｒの一番右上の対戦相手画像１５２１Ｂにかかる対戦相手が２番目にゲームオーバーになった状態を示す図である。２番目にゲームオーバーとなったため、順位として「９８位」が確定したことになる。また、対戦相手画像１５２１Ｂでは、「ＫＯ」の画像と順位を示す数値との間に、「Ｗａｔｃｈ」の文字列も表示されている。当該「Ｗａｔｃｈ」の文字列は、その対戦相手が観戦モードであることを示すものである。つまり、図１８の状態では、対戦相手画像１５２１Ａにかかる対戦相手は、ゲームオーバー後、観戦せずに対戦ゲームを終了しているが、対戦相手画像１５２１Ｂにかかる対戦相手は、ゲームオーバー後、観戦している状態であることを示している。このように、第２領域１５２には、対戦相手がゲームオーバーになった場合は、そのことを示す画像と順位が表示される。また、当該ゲームオーバーになった対戦相手が観戦することを選択した場合は、そのことを示す表示（上記例では「Ｗａｔｃｈ」の文字列の表示）も行われる。これにより、どの対戦相手がゲームオーバーになっているかについて把握しやすくすることできる。また、観戦モードの対戦相手がどの程度存在しているかについても把握しやすくすることができる。

上記説明した標的画像１６１、「ＣＡＵＴＩＯＮ」パネル１６２、直線１６３、バッジ画像１８１、待機ブロック画像１７１や「ＫＯ」の画像等の各表示要素は、言うまでもないが、実際のゲーム画像では同時に表示され得る。図１９に、これらの表示要素が同時に表示されているゲーム画像の例を示す。実際のゲームプレイでは、このような表示で、標的画像１６１および直線１６３の表示位置や、バッジ画像１８１および待機ブロック画像１７１の数等が刻々と変化しながら、ゲームが進行するものである。

このように、本実施形態にかかる対戦ゲームでは、９８人という多数の対戦相手から「標的」を選ぶために、ユーザに作戦を選択させ、これに基づいてプロセッサ８１が「標的」を設定している。これにより、どの対戦相手のゲーム状況（本例ではプレイフィールド１５１１の状況）に変化を与えるかについて、ユーザのゲーム操作を邪魔することなく、ユーザの意思をより反映させた決定を行うことが可能となる。

［本実施形態のゲーム処理の詳細］
次に、図２０〜図３３を参照して、本実施形態におけるゲーム処理についてより詳細に説明する。

［使用データについて］
まず、本ゲーム処理にて用いられる各種データに関して説明する。図２０は、本体装置２の記憶部８４に記憶される各種データの一例を示すメモリマップである。本体装置２の記憶部８４には、ゲームプログラム３０１、操作データ３０２、サーバ送信用データ３０５、更新用データ３０６、対戦相手データ３０７、現在モード３０８、待機ブロックデータ３０９、現在作戦データ３１０、現在バッジ数データ３１１、および、画像データ３１２等が記憶されている。

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

操作データ３０２は、上記左コントローラ３および右コントローラ４から得られるデータであり、ユーザの操作内容を示すデータである。当該操作データ３０２には、各コントローラが有する各種ボタンの押下状態を示すデジタルボタンデータ３０３、アナログスティックに対する操作内容を示すアナログスティックデータ３０４等が含まれている。

サーバ送信用データ３０５は、ゲームシステム１からサーバ１０１に送信するためのデータである。図２１に、当該サーバ送信用データ３０５の構成の一例を示す。図２１において、サーバ送信用データ３０５には、ユーザＩＤ３２１、プレイフィールド情報３２２、攻撃関連情報３２３、標的情報３２４、ゲームオーバー情報３２５、観戦情報３２６、バッジ情報３２７等が含まれている。

ユーザＩＤ３２１は、本ゲームに参加している９９人のユーザのそれぞれを一意に識別するための情報である。

プレイフィールド情報３２２は、上記プレイフィールド１５１１の状態を示すためのデータである。具体的には、縦２０×横１０マスのそれぞれについてのブロックの有無を示す情報が含まれている。また、ブロックが有る場合は、そのブロックの内容（例えば色・柄、形状等）を示す情報も含まれる。

攻撃関連情報３２３は、「標的」に対するお邪魔ブロックの送り込み（攻撃）が発生したか否かを示す情報である。また、お邪魔ブロックの送り込みが発生している場合は、送り込むお邪魔ブロックの行数（攻撃力）を示す情報も含まれる。換言すれば、当該攻撃関連情報３２３は、後述の標的情報３２４と合わせて、サーバ１０１を介して「標的」のゲームシステム１に対して、お邪魔ブロックを出現させる指示を行うためのデータであるといえる。

標的情報３２４は、上記「標的」を特定するための情報である。

ゲームオーバー情報３２５は、そのユーザがゲームオーバーになっているか否かを示す情報である。また、ゲームオーバーになった場合は、いずれかの対戦相手からお邪魔ブロックが原因でゲームオーバーとなったのか否かを示す情報と、当該原因となった対戦相手を特定するための情報が当該ゲームオーバー情報３２５に含まれる。

観戦情報３２６は、そのユーザが上記観戦モードであるか否かを示す情報である。観戦モードである場合は「観戦中」を示す情報が観戦情報３２６に設定される。

バッジ情報３２７は、そのユーザが現在所持しているバッジ数を示すデータである。

図２０に戻り、更新用データ３０６は、サーバ１０１から受信したデータであって、後述の対戦相手データ３０７を更新するためのデータである。図２２に、当該更新用データ３０６のデータ構成の一例を示す。更新用データ３０６は、基本的には、上記サーバ送信用データ３０５と同様の内容であるデータを１レコード（１行）としたテーブル形式のデータである。つまり、自分以外の他の９８人の対戦相手から送信されたサーバ送信用データ３０５をサーバ１０１経由で受信したものといえる。具体的には、図２１で示した各データを同趣旨のデータである、ユーザＩＤ３４１、プレイフィールド情報３４２、攻撃関連情報３４３、標的情報３４４、ゲームオーバー情報３４５、観戦情報３４６、バッジ情報３４７等が１レコードとして構成されている、テーブル形式のデータである。各データの説明については図２１で説明したものと同様のため、割愛する。

ここで、本実施形態の対戦ゲームでは、最大で９９人のユーザが参加できるが、必ずしも９９人が揃わなくてもよい。例えば、参加者が６０人しかいなかった場合は、サーバ１０１のプロセッサが残り３９人分のユーザとして振る舞う処理が実行される。このような場合、サーバ１０１において、プロセッサ８１が担当する３９人分のユーザ（以下、ＡＩユーザと呼ぶ）についてもそれぞれ上記サーバ送信用データ３０５と同様の内容のデータがＡＩユーザの行動結果に基づいて生成される。そして、これらを含むデータが各ゲームシステム１に送信され、各ゲームシステム１において上記更新用データ３０６として格納される。

また、更新用データ３０６には、例えば対戦相手同士での攻撃の応酬を示すデータが含まれていてもよい。すなわち、どの対戦相手がどの対戦相手を攻撃しているかを示すデータである。そして、このようなデータを用いて、第２領域１５２において、対戦相手同士の攻撃の様子を示す演出を表示するようにしてもよい。

なお、更新用データ３０６の送受信に関して、他の実施形態では、上記のようなテーブル形式のデータとして纏めて送受信するのではなく、ユーザ毎のデータを１件（図２２の１レコード）単位で送受信するようにしてもよい。各ゲームシステム１とサーバ間の通信速度の差や通信ラグ等の発生を踏まえて、例えば、各ユーザからのサーバ送信用データ３０５がサーバ１０１に届き次第、個別に他のユーザのゲームシステム１にこれを送信するような構成としてもよい。

図２０に戻り、次に、対戦相手データ３０７は、自分以外の９８人の対戦相手それぞれにかかるゲーム処理のゲーム状況を示すためのデータの一例であり、上記更新用データ３０６に基づいて適宜更新されるデータである。図２３に、対戦相手データ３０７の構成の一例を示す。対戦相手データ３０７は、上記第２領域１５２における９８個の対戦相手画像１５２１のうちの一つを特定するための画像枠番号３６０を含む。そして、この画像枠番号３６０に、上記更新用データ３０６と同様の内容である、ユーザＩＤ３６１、プレイフィールド情報３６２、攻撃関連情報３６３、標的情報３６４、ゲームオーバー情報３６５、観戦情報３６６、およびバッジ情報３６７を関連づけて記憶した、テーブル形式のデータである。すなわち、対戦相手それぞれから送られた上記サーバ送信用データ３０５を上記第２領域１５２における９８個の対戦相手画像１５２１のいずれかに割り当てたデータであるともいえる。

図２０に戻り、次に、現在モード３０８は、そのユーザが観戦モードであるか否か、あるいは、観戦モードへの遷移を問い合わせ中の状態（問い合わせ画面が表示されている状態）であるか否かを示すデータである。本例では、観戦モードへの遷移を問い合わせ中の
状態であれば「問い合わせ中」を示すデータが設定され、観戦モードに入っている場合は「観戦中」を示すデータが設定されるものとする。

待機ブロックデータ３０９は、上記待機ブロック領域１５１２に表示される待機ブロック画像１７１に関するデータである。図２４に、待機ブロックデータ３０９のデータ構成の一例を示す。待機ブロックデータ３０９には、待機番号３３１と、対戦相手ＩＤ３３２と、攻撃力３３３と、経過時間３３４とが含まれる。待機番号３３１は、各待機ブロック画像１７１（すなわち待機ブロック）を識別するための番号である。対戦相手ＩＤ３３２は、当該待機ブロックを送り込んだ対戦相手のユーザＩＤを示す情報である。攻撃力３３３は、出現するお邪魔ブロック１７３の行数を示す情報である。経過時間３３４とは、当該待機ブロックが送り込まれてから経過した時間を示す。

図２０に戻り、次に、現在作戦データ３１０は、現在選択されている上記作戦を示すデータである。現在バッジ数データ３１１は、そのユーザが現在所持している上記バッジ数を示すデータである。また、画像データ３１２は、各種ブロックの画像や標的画像等の、本ゲーム処理で表示される各種画像のデータである。

［サーバに記憶されるデータ］
次に、サーバ１０１で用いられるデータに関して説明する。図２５は、サーバ１０１の記憶部１１２に記憶される各種データの一例を示すメモリマップである。サーバ１０１の記憶部１１２には、サーバ処理プログラム３２１、参加ユーザデータ３８２、受信データ３８３、送信データ３８４等が記憶されている。

サーバ処理プログラム３８１は、本実施形態にかかるゲーム処理においてサーバ１０１が担当する機能を処理させるためのプログラムである。主に、各ゲームシステム１から送信されるサーバ送信用データ３０５の受信処理、上記ＡＩユーザの処理が必要な場合は、ＡＩユーザとしてゲームを進行する処理、各ゲームシステム１に送信するデータを生成して送信する処理、等が当該プログラムによって実行される。

参加ユーザデータ３８２は、本実施形態にかかる最大９９人の対戦ゲームに参加したユーザに関するデータである。そのデータ構成としては、ゲームへの参加者９９人分の上記サーバ送信用データ３０５の内容で構成されるテーブル形式のデータとなる。そのため、当該データの構成の詳細な説明は割愛する。

受信データ３８３は、各ゲームシステム１から送信されてきたサーバ送信用データ３０５を一時的に記憶したデータである。このデータに基づいて上記参加ユーザデータ３８２が更新される。

送信データ３８４は、各ゲームシステム１に、対戦相手の状況を送信するためのデータである。本実施形態では、そのデータ構成としては、上記参加ユーザデータ３８２の内容から、送信先のゲームシステム１にかかるユーザのデータを抜いた内容であるものとする。

［全体的な処理の流れ］
次に、本実施形態にかかるゲーム処理の詳細を説明する。まず、図２６を用いて、サーバ１０１および各ゲームシステム１との協働による全体的な処理の流れを説明する。図２６においては、図の左側にゲームシステム側処理、右側にサーバ側処理を示している。まず、対戦ゲームの開始が所定のユーザによって指示されることで、各ゲームシステム１およびサーバ１０１との間で準備処理Ｐ１が実行される。この処理では、締め切り時間を設定したうえで、最大９９人のユーザの参加受付が行われる。その後、締め切り時間が経過
すれば、参加者が９９人に足りない場合はその分のＡＩユーザの設定が適宜行われ、当該ＡＩユーザを含む対戦相手の情報が各ゲームシステムに送信され、上記のようなパズルゲームを実行する処理Ｐ２が開始される。その後、ゲームオーバーになったユーザが出てきたときは、必要に応じて、上記のようにゲームオーバーに追い込んだことユーザに対して、獲得したバッジ数を示す情報（以下、獲得バッジ情報）を所定のユーザに送信する処理が実行される。更に、ゲームオーバーとなったユーザが９８人になれば、サーバ１０１は各ゲームシステムに、最終的な順位が確定した旨と、各ユーザの最終順位とユーザ名等を示す情報（以下、終了処理用データと呼ぶ）を送信する。その後、各ゲームシステムで最終順位の表示等の処理が実行され、当該ゲームを終了する処理Ｐ３（通信セッションの切断等）が行われることで、本実施形態にかかるゲームは終了となる。

［ゲームシステム側で実行される処理の詳細］
次に、各ゲームシステム１で実行されるゲーム処理の詳細を説明する。図２７〜図２９は、本ゲーム処理の詳細を示すフローチャートである。また、この処理は、上記締め切り時間が終了した後に実行される処理である。また、当該図面で示すフローチャートは、処理過程の単なる一例にすぎない。したがって、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判断ステップで利用される閾値も、単なる一例に過ぎず、必要に応じて他の値を採用してもよい。

まず、図２７のステップＳ１で、ゲームを開始するための各種の準備処理が実行される。具体的には、プロセッサ８１は、各対戦相手の情報が含まれている更新用データ３０６をサーバから受信する。そして、これに基づき、各対戦相手を上記第２領域１５２の対戦相手画像１５２１のいずれかに割り当てることで、対戦相手データ３０７を生成する。また、図示は省略するが、落下するブロックの順番を示す落下順番データもこの時点でサーバ１０１から受信し、記憶部８４に格納しておく。この後に実行されるパズルゲームでは、当該落下順番データに基づいた順番で上記ブロックが出現し、また、ネクストブロック領域１５１３の表示内容も適宜更新される。また、プロセッサ８１は、上記作戦の初期値として「ランダム」を示す情報を現在作戦データ３１０に設定する。

その後、上記対戦相手データ３０７に基づいて第２領域１５２に表示する画像が生成され、また、上記落下順番データ等に基づいて第１領域１５１に表示する画像も生成される。そして、これら画像を含むゲーム画像がディスプレイ１２に出力される。その後、所定のカウントダウン演出が行われて、パズルゲームが開始される。なお、以下のステップＳ２〜Ｓ２９の処理ループは、例えば１フレーム毎に繰り返し実行されるものとする。

次に、ステップＳ２で、プロセッサ８１は、更新用データ３０６をサーバから受信する。また、その他、上記獲得バッジ数データ、上記終了処理用データがあれば、当該データの受信も行われる。

続くステップＳ３で、プロセッサ８１は、各種データを更新する処理を実行する。まず、プロセッサ８１は、更新用データ３０６に基づいて対戦相手データ３０７を更新する。これにより、対戦相手のゲーム進行状況が更新されることになる。なお、当該対戦相手データの更新間隔については、１フレーム毎ではなく、例えば１秒間隔等の所定間隔での更新としてもよい。本ゲームは、基本的にはパズルゲーム自体は各ゲームシステム１で独立して進行可能であるため、それほど厳密には他のゲームシステム１との間で同期を取らなくてもよいからである（本ゲームでは、通信について多少のタイムラグがあっても、その影響は小さいと考えられる）。また、その他、更新後の対戦相手データ３０７の攻撃関連情報３６３に基づき、待機ブロックデータ３０９の内容も適宜更新される。つまり、対戦相手から受けた攻撃に関して反映する処理も実行される。

更に、ステップＳ２で獲得バッジ数データを受信していれば、これに基づいて現在バッジ数データ３１１およびバッジ情報３２７に所定の値が加算され、これらのデータが更新される。上記のように、「標的」を自身の送り込んだお邪魔ブロックでゲームオーバーに追い込んだ場合に、獲得バッジ数データがサーバ１０１から送信され、所定数のバッジを獲得できる。

次に、ステップＳ４で、プロセッサ８１は、今回の対戦ゲームの終了条件が満たされたか否かを判定する。具体的には、上記ステップＳ２において、サーバ１０１から上記終了処理用データを受信しているか否かが判定される。その結果、終了条件が満たされていた場合は（ステップＳ４でＹＥＳ）、ステップＳ６で、プロセッサ８１は、今回の対戦ゲームを終了するための処理を実行する。具体的には、サーバ１０１から受信した上記終了処理用データに基づいて、各ユーザの最終順位を表示する等の処理を実行する。その後、サーバ１０１との通信を切断するための処理を実行して本ゲーム処理は終了する。

一方、上記ステップＳ４の判定の結果、終了条件が満たされていない場合は（ステップＳ４でＮＯ）、ステップＳ５で、プロセッサ８１は、待機ブロックデータ３０９を参照し、その時点で存在している待機ブロックについての経過時間３３４を更新する。例えば、経過時間３３４をカウントアップする処理が実行される。

次に、ステップＳ７で、プロセッサ８１は、操作データ３０２を取得する。次に、ステップＳ８で、プロセッサ８１は、現在モード３０８が「観戦中」であるか否かを判定する。つまり、ユーザが（既にゲームオーバーとなっていて）観戦モードに入っているか否かを判定する。当該判定の結果、「観戦中」の場合は（ステップＳ８でＹＥＳ）、後述するステップＳ２６に処理が進められる。

一方、「観戦中」ではない場合は（ステップＳ８でＮＯ）、次に、ステップＳ９で、プロセッサ８１は、現在モード３０８が「問いあわせ中」であるか否かを判定する。「問いあわせ中」の場合は、図２８のステップＳ１２で、プロセッサ８１は、操作データ３０２で示される操作内容が観戦モードへの遷移指示であるか否かを判定する。その結果、遷移指示が行われていた場合は（ステップＳ１２でＹＥＳ）、ステップＳ１３で、プロセッサ８１は、当該ユーザがゲームオーバーになったことを示す情報を含むようにゲームオーバー情報３２５を更新する。更に、ステップＳ１４で、プロセッサ８１は、現在モード３０８および、上記サーバ送信用データ３０５の観戦情報３２６に「観戦中」を示す情報を設定する。その後、後述のステップＳ２６に処理が進められる。

一方、ステップＳ１２の判定の結果、遷移指示が行われていない場合は（ステップＳ１２でＮＯ）、ステップＳ１５で、プロセッサ８１は、操作データ３０２で示される操作内容がゲームを終了する旨の指示であるか否かを判定する。つまり、ゲームオーバーになった後、観戦せずにゲームを終了することがユーザによって選択されたか否かが判定される。終了指示である場合は、ステップＳ１６で、プロセッサ８１は、当該ユーザがゲームオーバーになったことを示す情報を含むようにゲームオーバー情報３２５を更新する。続くステップＳ１７で、プロセッサ８１は、サーバ送信用データ３０５をサーバ１０１に送信する処理を実行する。その後、ステップＳ１８で、プロセッサ８１は、当該ゲームを終了するための処理を実行する。なお、上記ステップＳ６の処理とは異なり、ここでは、最終順位の表示等は行われずに、ゲーム処理が終了される（いわば、ゲームから途中退出するような処理となる）。また、上記ステップＳ１７における送信処理により、サーバ１０１（および他の対戦相手）には、当該ユーザがゲームオーバーになったこと、および、その後の観戦はしないことが通知されることになる。

図２７に戻り、上記ステップＳ９の判定の結果、「問いあわせ中」ではない場合は（ス
テップＳ９でＮＯ）、ステップＳ１０で、プロセッサ８１は、操作データで示される操作内容が上述したような作戦の変更操作であるか否か（本例では、右コントローラ４が備えるアナログスティックの操作）が判定される。当該判定の結果、作戦の変更操作が行われていた場合は（ステップＳ１０でＹＥＳ）、操作データ３０２で示される操作内容に基づいて、現在作戦データ３１０の内容が更新される。その後、後述のステップＳ２６に処理が進められる。

一方、ステップＳ１０の判定の結果、作戦変更操作が行われていない場合は（ステップＳ１０でＮＯ）、次に、図２９のステップＳ１９で、プロセッサ８１は、現在作戦データ３１０を参照して、現在選択されている作戦に基づいて、上記「標的」を選択する処理を実行する。具体的には、以下のような処理がプロセッサ８１によって実行される。まず、現在の作戦が「とどめ狙い」の場合は、プロセッサ８１は、上記対戦相手データ３０７を参照し、各対戦相手のプレイフィールド情報３６２に基づいて、上述したような「ピンチ状態」になっている対戦相手を抽出する。抽出の結果、「ピンチ状態」の対戦相手が１人だけであれば、その対戦相手を「標的」として設定するため、標的情報３２４に当該対戦相手を示すユーザＩＤ３６１を設定する。また、「ピンチ状態」の対戦相手が複数いた場合は、そのうちの１人を「標的」として決定して（決定の仕方はどのような手法でもよい）、標的情報３２４に設定する。また、現在の作戦が「ランダム」であれば、プロセッサ８１は、対戦相手からランダムで１人を選択して、当該対戦相手を示すユーザＩＤ３６１を標的情報３２４に設定する。また、現在の作戦が「バッジ狙い」の場合は、プロセッサ８１は、上記対戦相手データ３０７を参照し、各対戦相手のバッジ情報３６７に基づいて所定の対戦相手を選択し、当該対戦相手を示すユーザＩＤ３６１を標的情報３２４に設定する。また、現在の作戦が「カウンター」の場合は、プロセッサ８１は、上記対戦相手データ３０７を参照し、標的情報３６４に基づいて自分を「標的」として設定している対戦相手を特定する。そして、特定した対戦相手のユーザＩＤ３６１（複数いた場合はその全員分のユーザＩＤ３６１）をサーバ送信用データ３０５の標的情報３２４に設定する。

次に、ステップＳ２０で、プロセッサ８１は、操作データに基づいて、あるいは、時間の経過に基づいて、上記ブロックをプレイフィールド１５１１内で移動させる。操作データ３０２で示される操作内容がブロックの左右、下方向の移動、または回転させる操作であれば、当該操作内容に応じてブロックを移動あるいは回転させる。また、ブロックに対するユーザからの操作がなかった場合でも、所定の時間が経過する毎に、ブロックを１マス分下方向に移動させる処理も行われる。

次に、ステップＳ２１で、プロセッサ８１は、ブロックの配置位置が確定されたか否かを判定する。まだ確定されていない場合は（ステップＳ２１でＮＯ）、後述のステップＳ２３に処理が進められる。確定した場合は（ステップＳ２１でＹＥＳ）、ステップＳ２２で、プロセッサ８１は、ブロック消去関連処理を実行する。

図３０は、当該ブロック消去関連処理の詳細を示すフローチャートである。まず、ステップＳ４１で、プロセッサ８１は、上記ブロックの配置が確定した結果、ブロックの消去条件が満たされたか否かを判定する。本実施形態では、プレイフィールド１５１１の横１行分が埋まったブロックがあるか否かが判定される。当該判定の結果、消去条件が満たされていない場合は（ステップＳ４１でＮＯ）、後述のステップＳ４９の処理に進む。一方、消去条件が満たされている場合は（ステップＳ４１でＹＥＳ）、次に、ステップＳ４２で、プロセッサ８１は、消去するブロックにかかる行数を算出する。つまり、何行分消去できるのかが算出される。

次に、ステップＳ４３で、消去する行数に基づいて、上記基礎攻撃力を算出する。本例では、消去する行数と基礎攻撃力とが同じ値であるものとする。例えば消去行数が１であ
れば基礎攻撃力は１、消去行数が３であれば基礎攻撃力は３である。

次に、ステップＳ４４で、プロセッサ８１は、待機ブロックデータ３０９を参照して、現在、待機ブロックが存在しているか否かを判定する。存在していない場合は（ステップＳ４４でＮＯ）、後述のステップＳ４７に処理が進められる。存在している場合は（ステップＳ４４でＹＥＳ）、続くステップＳ４５で、消去する行数と待機ブロックとを相殺する処理が実行される。例えば、待機ブロック画像１７１が３個存在している状態で２行消去できる場合は、待機ブロックデータ３０９の攻撃力３３３から２を減算する。これに応じて、画面に表示されている待機ブロック画像１７１を減らすための処理も実行される。また、当該減算の結果、攻撃力が０以下になった場合は、当該攻撃力が０となった待機ブロックにかかるレコードを待機ブロックデータ３０９から削除する処理も実行される。また、例えば、待機ブロックデータ３０９において、待機番号３３１が”１”の待機ブロックと待機番号３３１が”２”の待機ブロックとがある場合を想定する。そして、待機番号３３１が”１”の待機ブロックの攻撃力が”１”であり、待機番号３３１が”２”の待機ブロックの攻撃力が”３”であったとする。この場合に、２行消去した場合は、待機番号３３１が”１”の待機ブロックは完全に相殺され、待機番号３３２が”２”の待機ブロックについては１行分だけ相殺される（攻撃力３３３が２に減算される）ことになる。つまり、待機番号３３１が小さい順に相殺されていく。

次に、ステップＳ４６で、プロセッサ８１は、上記相殺した内容に応じて、基礎攻撃力を減算する。例えば１行分の相殺が行われていた場合は、基礎攻撃力から”１”が減算される。

次に、ステップＳ４７で、プロセッサ８１は、上記基礎攻撃力を、バッジ情報３２７で示される自身のバッジの所持数に基づき補正する。更に、現在選択されている作戦が「カウンター」である場合は、自分を「標的」にしている対戦相手の数に基づいて補正する。例えば、バッジの所持数が１である場合は、基礎攻撃力に１が加算される。更に、「カウンター」作戦の場合であって、３人の対戦相手から「標的」にされている場合は（上記対戦相手データ３０７に基づいて判別可能である）、バッジによる加算とは別に、基礎攻撃力に更に１が加算される。一例ではあるが、「基礎攻撃力＋バッジ数による補正攻撃力＋「カウンター」作戦による補正攻撃力」が「標的」に対する最終的な攻撃力として算出されることになる。そして、このように算出された攻撃力を、「標的」への攻撃が発生したことを示す情報と共に、サーバ送信用データ３０５の攻撃関連情報３２３に設定する。

次に、ステップＳ４８で、プロセッサ８１は、上記ブロックの消去に伴い、プレイフィールド１５１１の内容を更新する処理を実行する。つまり、上記消去後のブロックの配置を更新する処理が実行される。

次に、ステップＳ４９で、プロセッサ８１は、お邪魔ブロック処理を実行する。図３１は、当該お邪魔ブロック処理の詳細を示すフローチャートである。図３１において、まず、ステップＳ６１で、プロセッサ８１は、待機ブロックデータ３０９を参照して、経過時間３３４が予め設定されている所定の待機時間を越えた待機ブロックがあるか否かを判定する。当該判定の結果、このような待機ブロックがない場合は（ステップＳ６１でＮＯ）、当該お邪魔ブロック処理は終了する。一方、このような待機ブロックがある場合は（ステップＳ６１でＹＥＳ）、次に、ステップＳ６２で、プロセッサ８１は、上記お邪魔ブロック１７３を生成する。具体的には、待機ブロックデータ３０９の攻撃力３３３に基づいて、出現させるお邪魔ブロック１７３の行数を決定する。そして、各行にかかるお邪魔ブロック１７３の内容を決定する。本例では、上記図１０を用いて説明したように、横１行分のうちいずれか１マスだけランダムで空白にした９個分のブロックがお邪魔ブロック１７３として生成される。

次に、ステップＳ６３で、プロセッサ８１は、上記生成したお邪魔ブロック１７３をプレイフィールド１５１１に配置し、配置後のプレイフィールド１５１１の内容を更新する処理を実行する。本例では、下からせり上がるようにしてお邪魔ブロックが配置される。また、出現させたお邪魔ブロック１７３に対応する待機ブロックについては、待機ブロックデータ３０９から削除する処理も実行される、また、これに伴い、対応する待機ブロック画像１７１を待機ブロック領域１５１２から消去する処理も実行される。その後、お邪魔ブロック処理は終了する。

図３０に戻り、次に、ステップＳ５０で、プロセッサ８１は、上記落下順番データに基づき、次に落下してくるブロックを表示するための処理を実行する。また、ネクストブロック領域１５１３の表示内容を更新する処理も実行する。その後、ブロック消去関連処理は終了する。

図２９に戻り、次に、ステップＳ２３で、プロセッサ８１は、プレイフィールド１５１１の状況が、ゲームオーバーとなる条件を満たしたか否かを判定する。本例では、プレイフィールドの最上段までブロックが積み上がった場合にゲームオーバーの条件を満たしたと判定される。当該判定の結果、ゲームオーバーではない場合は（ステップＳ２３でＮＯ）、ステップＳ２４で、プロセッサ８１は、プレイフィールド１５１１の状況が、上記「ピンチ状態」であるか否かを判定する。その結果、「ピンチ状態」でなければ（ステップＳ２４でＮＯ）、ステップＳ２６に処理が進められる。一方、「ピンチ状態」であれば（ステップＳ２４でＹＥＳ）、ステップＳ２５で、プロセッサ８１は、「ピンチ状態」であることを示すようにプレイフィールド１５１１の表示態様を変化させる。

次に、ステップＳ２６で、プロセッサ８１は、上記処理の内容を反映したゲーム画像を生成し、ディスプレイ１２に出力する。具体的には、上記対戦相手データ３０７のプレイフィールド情報３６２に基づいて、上記第２領域１５２に表示する画像、すなわち、合計９８個の対戦相手画像１５２１を生成する。また、プロセッサ８１は、標的情報３２４に基づき、標的画像１６１を自分が標的としている対戦相手画像１５２１に重畳する。また、プロセッサ８１は、対戦相手データ３０７の標的情報３６４に基づき、上記「ＣＡＵＴＩＯＮ」パネル１６２をプレイフィールド１５１１の下部に配置し、更に、自分を狙っている対戦相手にかかる対戦相手画像１５２１と、上記「ＣＡＵＴＩＯＮ」パネル１６２とを結ぶ上記直線１６３を生成して配置する。また、プロセッサ８１は、待機ブロックデータ３０９、現在作戦データ３１０、現在バッジ数データ３１１に基づき、待機ブロック領域１５１２、バッジ表示領域１５１４、作戦操作パネル１５１５の表示内容も決定する。また、プロセッサ８１は、ゲームオーバー情報３６５を参照して各対戦相手がゲームオーバーとなっているか否かを判定する。対戦相手がゲームオーバーとなっている場合は、更に観戦情報３６６に基づいて、その対戦相手が観戦モードであるか否かを判定する。そして、当該判定の結果に基づいて、ゲームオーバーであること、および、観戦しているか否かを示す画像（上記図１７、図１８参照）を対戦相手画像１５２１として生成する。これにより、９８人の対戦相手のゲームの状況をユーザに提示することができる。更に、プロセッサ８１は、上記第１領域１５１に表示する画像として、上記のようなプレイフィールド１５１１に関する各種処理が反映された画像も生成する。但し、ユーザがゲームオーバーとなり、観戦モードにはいっている場合は、それ以上プレイフィールド内容の更新は行われないため、ゲームオーバー時のプレイフィールド１５１１の状態を示す画像が生成される。そして、これらを組み合わせて、出力すべきゲーム画像が生成され、ディスプレイ１２に出力される。

続くステップＳ２７で、プロセッサ８１は、サーバ送信用データ３０５のプレイフィールド情報３２２の内容を、上記の処理が反映された後のプレイフィールド１５１１の状況
を示すように更新する処理を実行する。なお、ユーザがゲームオーバーとなった後（現在モード３０８が「問いあわせ中」または「観戦中」の場合）は、当該プレイフィールド情報３２２の更新は行われない。

次に、ステップＳ２８で、プロセッサ８１は、サーバ送信用データ３０５をサーバ１０１に送信する処理を実行する。その後、上記ステップＳ２に戻り、処理が繰り返される。

一方、上記ステップＳ２３の判定の結果、ゲームオーバーである場合は（ステップＳ２３でＹＥＳ）、ステップＳ２９で、ゲームオーバー処理が実行される。図３２は、当該ゲームオーバー処理の詳細を示すフローチャートである。まず、ステップＳ８１で、プロセッサ８１は、今回のゲームオーバーが、お邪魔ブロック１７３の出現によるゲームオーバーであるか否かを判定する。その結果、お邪魔ブロック１７３の出現によるものではない場合は（ステップＳ８１でＮＯ）、ステップＳ８３に処理が進められる。一方、お邪魔ブロック１７３の出現によるものであった場合は（ステップＳ８１でＹＥＳ）、ステップＳ８２で、プロセッサ８１は、ゲームオーバー情報３２５の更新を行う。具体的には、プロセッサ８１は、当該お邪魔ブロック１７３を送り込んだ対戦相手にバッジを獲得させるための情報をゲームオーバー情報３２５に設定する処理を実行する。すなわち、当該お邪魔ブロックを送り込んだ対戦相手のユーザＩＤ、および、その時点でユーザが所持しているバッジ数を示す情報を含むようにゲームオーバー情報３２５が設定される。これにより、ここで示される対戦相手に対して当該ユーザがその時点で所持していたバッジを付与することができる。

次に、ステップＳ８３で、プロセッサ８１は、現在モード３０８に「問いあわせ中」を設定する。次に、ステップＳ８４で、プロセッサ８１は、観戦するか否かをユーザに問いあわせる問い合わせ画面を生成し、ディスプレイ１２に出力する。以上で、ゲームオーバー処理は終了する。ゲームオーバー処理が終われば、上記ステップＳ２に戻り、処理が繰り返される。

以上で、各ゲームシステム１で実行されるゲーム処理の詳細説明を終了する。

［サーバ側の処理の詳細］
次に、サーバ１０１で実行される処理の詳細について説明する。図３３は、サーバのプロセッサ１１１によって実行されるサーバ処理の詳細を示すフローチャートである。まず、ステップＳ１０１で、プロセッサ１１１は、準備処理を実行する。具体的には、ゲームに参加する各ゲームシステム１から送信されるデータに基づいて上記参加ユーザデータ３８２を生成する。この際、上記参加人数が９９人に足りていない場合は、足りない分のユーザをＡＩユーザとしてプロセッサ１１１が担当する。そのため、このＡＩユーザにかかるデータも参加ユーザデータ３８２に含めるようにして生成する。その後、対戦ゲーム開始の準備が整えば、対戦ゲームの開始を示す情報を各ゲームシステム１に送信する。

次に、ステップＳ１０２で、プロセッサ１１１は、参加ユーザデータ３８２を参照して、ゲーム終了条件が満たされたか否かを判定する。例えば、ゲームオーバーとなったユーザが９８人に達したか否かを判定する。当該判定の結果、終了条件が満たされていない場合は（ステップＳ１０２でＮＯ）、ステップＳ１０３で、プロセッサ１１１は、受信処理を実行する、すなわち、各ゲームシステム１から送信されてくるサーバ送信用データ３０５を受信する。

次に、ステップＳ１０４で、プロセッサ１１１は、上記ＡＩユーザにかかるパズルゲーム処理を実行する。なお、ＡＩユーザが不要な場合は、当該処理は行われない。

次に、ステップＳ１０５で、プロセッサ１１１は、上記受信したデータ、および、上記ＡＩユーザのパズルゲーム処理の結果に基づいて、参加ユーザデータ３８２を更新する。

次に、ステップＳ１０６で、プロセッサ１１１は、ゲームオーバー時の上記バッジの獲得に関する処理を実行する。すなわち、参加ユーザデータに含まれるゲームオーバー情報に基づいて、所定のユーザにバッジを獲得させるための処理を実行する。例えば、ユーザＡがユーザＢから送り込まれたお邪魔ブロックによりゲームオーバーとなった場合は、ユーザＡから送信されるゲームオーバー情報３２５にこのことを示す情報が含まれている。これに基づき、プロセッサ１１１は、ユーザＢに対してバッジを１つ獲得させることを決定する。更に、当該ユーザＡのバッジ情報３２７を参照し、ユーザＡが１以上のバッジを所持していた場合は、そのバッジ数を更に加算してユーザＢに獲得させることを決定する。そして、ユーザＢに獲得させるバッジ数を示す情報を、ユーザＢを宛先とする上記獲得バッジ数データとして生成する。

次に、ステップＳ１０７で、プロセッサ１１１は、各ゲームシステム１に送信するための送信データを生成する。具体的には、送信先のゲームシステム１にかかるユーザ以外のユーザにかかるデータを送信データとして生成する。例えばユーザＡに対する送信データとしては、ユーザＡ以外の９８人分のユーザのデータを含む送信データが生成される。また、上記獲得バッジ数データを生成していた場合は、該当するユーザに対する送信データに当該データを含める。そして、ゲームに参加している各ゲームシステム１に送信データを送信する。なお、このとき、ゲームオーバーになったユーザであって、観戦しないことを選んだユーザにかかるゲームシステム１に対しては、送信しないようにしてもよい。当該処理の後、上記ステップＳ１０２に戻って処理が繰り返される。

一方、上記ステップＳ１０２の判定の結果、ゲーム終了条件が満たされていた場合は（ステップＳ１０２でＹＥＳ）、ステップＳ１０８で、プロセッサ１１１は、最終順位等の情報を含めた上記終了処理用データを生成し、各ゲームシステム１に対して送信する。なお、この場合も、ゲームオーバーになったユーザであって、観戦しないことを選んだユーザにかかるゲームシステム１に対しては、送信しないようにしてもよい。

以上で、サーバ側の処理の説明を終了する。

このように、本実施形態では、９８人という多数の対戦相手が存在する対戦ゲームにおける攻撃対象相手の選択について、上記のような「作戦」を選択させることにより、ユーザの意思を反映させつつも容易な選択操作が可能となっている。これにより多数の相手と対戦するようなゲームにおいて、攻撃対象とする等で相手を指定する必要性があるゲームにおける選択のやりやすさをより向上させることができる。

また、上記のような多数の対戦相手それぞれに対応づけられた画像も表示し、上記標的画像１６１や「ＣＡＵＴＩＯＮ」パネル１６２および直線１６３を表示している。これにより、自分が誰を選択しているか、あるいは、自分が誰から選択されているかをよりわかりやすく提示できる。

［変形例］

なお、上記実施形態では、各ユーザの順位表示については、ゲームオーバーとなって順位が確定したときに表示する例を示した。この他、他の実施形態では、リアルタイムに順位を表示するようにしてもよい。例えば、上記のような対戦ゲームにおいて上述した「バッジ」の所持数で順位を決めるような場合は、各ユーザのバッジの所持数に応じて、例えば対戦相手画像１５２１に重畳してその時点での順位を表示してもよい。そして、バッジ
所持数の変化に応じてリアルタイムに順位表示を変更するようにしてもよい。

また、上記実施形態では、「標的」としている対戦相手画像１５２１の重畳するようにして標的画像１６１を表示していた。他の実施形態では、標的画像１６１を表示する代わりに、当該対戦相手画像１５２１自体の表示態様を変化させるようにしてもよい。例えば、その大きさを少し拡大して表示してもよいし、当該対戦相手画像１５２１に所定のアニメーション演出を行うようにしてもよい。

また、対戦相手のゲーム状況を変化させる手法の一例として、上記の説明では「お邪魔ブロック」に対戦相手に送り込むことで対戦相手のパズルゲームの進行を妨害する例を用いて説明していた。対戦相手のゲーム状況を変化させる手法はこれに限るものではない。他の実施形態では、例えば、対戦相手の体力・ＨＰ等の耐久力を減少させたり、対戦相手の持ち時間を減少させたり、対戦相手が行っているゲーム操作を一時的に受け付けないようにする等、対戦相手のゲーム進行の妨害となるような内容であれば、上記「お邪魔ブロック」以外の手法を用いてもよい。

また、第２領域１５２における表示に関して、上記実施形態では、ゲームオーバーとなった対戦相手の表示として、上記図１７で示したような「ＫＯ」の画像等を表示していた。すなわち、ゲームオーバーになった場合にその表示を変更していた。この点に関して、他の実施形態では、第２領域１５２を用いて、いわゆるビンゴゲームの要素を利用した処理を行ってもよい。つまり、７×７の配列で対戦相手画像１５２１が並べられている中で、ユーザの攻撃によってゲームオーバーになったユーザにかかる対戦相手画像１５２１が、縦・横・斜めのいずれか一列に並んだことに応じて（ビンゴの成立）、例えば上記攻撃力の向上等、何らかの効果を付与するようにしてもよい。これにより、ゲームの興趣性を更に高めることが可能となる。

また、他の実施形態では、図５で示したようなゲーム画像構成を利用して、４９ｖｓ４９のチームバトルとして上記のようなゲームを実行してもよい。例えば、ユーザは２つのチームのいずれかに属し、上記図５における第２領域１５２Ｌには、ユーザ自身を含む４９人の味方チームのプレイフィールド１５１１の状況を示す４９個の対戦相手画像１５２１が表示される。第１領域１５１には、上記実施形態同様にユーザが操作するプレイフィールド１５１１等が表示される。そして、第２領域１５２Ｒには、残り４９人のユーザで構成される敵チームにかかる４９個の対戦相手画像１５２１が表示される。この場合は、「標的」として設定できる相手を敵チームにかかる対戦相手に限定すればよい。そのため、上記標的画像１６１や直線１６３については、第２領域１５２Ｒの対戦相手画像１５２１のいずれかを対象として表示されることになる。これにより、上記実施形態と同様のゲーム画像構成や表示要素を利用して、チーム戦という上記実施形態とは別のゲーム性を有する対戦ゲームを実現することができる。

また、他の実施形態では、上記サーバ１０１を介さずに、例えば近距離無線通信等を用いてゲームシステム１同士で接続（ピア・ツー・ピア）して、上述したような対戦ゲーム処理を行うような構成としてもよい。

また、例えば、ユーザは１人で、残り９８人の対戦相手全てを上記ＡＩユーザとして、単一のゲームシステム１だけで上記のゲーム処理を実行するような構成でもよい。この場合、上記ゲーム状況を示すデータのやりとりについては当該ゲームシステム１内で完結するような構成となる。例えばプロセッサ８１が担当する９８人分のＡＩユーザにかかる上記サーバ送信用データ３０５を、サーバ１０１に送信する代わりに記憶部８４に更新用データ３０６として格納するような構成とすればよい。

また、上記実施形態では、上から落下してくるパズルオブジェクトを積み上げ、横１行並べて消去するようなアクションパズルゲーム処理を例にしたが、このようなパズルゲームに限らず、様々なアクションパズルゲーム処理についても上記のような処理は適用可能である。例えば、上記パズルオブジェクトが下方から上に向かって出現するようなパズルゲーム処理等にも適用できる。

また、上記実施形態では、ゲーム処理の一例として、パズルゲームを例に挙げて説明したが、ゲーム処理はパズルゲーム処理に限るものではない。他の実施形態では、ユーザと複数の対戦相手とのそれぞれにかかるゲーム処理が独立して進行するゲームであれば、パズルゲーム以外のゲーム処理に上記のような処理を適用してもよい。

また、第１領域１５１と第２領域１５２の配置位置関係に関して、上記の例ではゲーム画像の中央に第１領域１５１を配置し、その左右に２つの第２領域１５２を配置する例を示した。これに限らず、第２領域１５２の位置に関しては、例えば第１領域１５１の上下であってもよい。更には、第２領域１５２の位置は固定せず、例えば第１領域１５１の周囲を周回するように常に移動させるようにしてもよい。

また、上記のゲーム処理は、上述したゲームシステム１に限らず、例えば携帯型ゲーム装置やスマートフォン等の情報処理装置でも実行可能である。ここで、表示画面を２つ備える携帯型ゲーム装置で上記の処理を実行する場合は、例えば第１の表示画面に上記第１の領域（ユーザのゲームプレイに関する画像）を表示し、第２の表示画面に上記第２領域（つまり、９８人の対戦相手にかかる対戦相手画像１５２１）を表示するような構成としてもよい。

また、他の実施形態においては、各ユーザのゲーム処理にかかる上記一連の処理について、複数の情報処理装置からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの一部の処理がサーバ側装置によって実行されてもよい。更には、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。例えば、主要なゲーム処理はサーバ側装置で実行し、端末側装置では主にサーバ側装置でのゲーム処理の結果生成されたゲーム画像を受信して表示させることでゲームを進行させるようにしてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。

１ ゲームシステム
２ 本体装置
３ 左コントローラ
４ 右コントローラ
１２ ディスプレイ
８１ プロセッサ
８４ 記憶部

Claims (17)

1. ユーザに対戦ゲームを提供するための情報処理装置のコンピュータにおいて実行されるゲームプログラムであって、前記コンピュータを、
   当該ユーザの対戦相手に関連する第２ゲーム処理とは独立して進行する第１ゲーム処理を前記ユーザの操作に基づいて実行するゲーム実行手段と、
   複数の前記対戦相手に関連する前記第２ゲーム処理の第２ゲーム状況を示す状況データを逐次取得する取得手段と、
   前記第１ゲーム処理の第１ゲーム状況を反映した画像である第１画像と、前記取得手段によって取得した複数の前記状況データが示す前記第２ゲーム状況を反映した画像である複数の第２画像とを含む表示用画像を逐次生成する画像生成手段と、
   複数の前記対戦相手の中から少なくとも１を選択するための方針であって、予め設定されている複数の方針のうち、前記ユーザの操作に基づいていずれか１の方針を選択する方針選択手段と、
   前記選択された方針に基づいて、複数の前記対戦相手のうち、少なくとも１を標的として特定する特定手段と、
   前記ユーザのゲーム状況が所定の条件を満たす場合、前記特定手段によって標的として特定された対戦相手のゲーム状況を変化させるための指示を行う変化指示手段として機能させる、ゲームプログラム。
2. 前記取得手段は、複数の前記対戦相手のそれぞれが前記ユーザを標的として特定しているか否かを示す被特定情報データを含む前記状況データを逐次取得し、
   前記画像生成手段は、前記対戦相手が前記ユーザを標的として特定していることを前記被特定情報データが示す場合、当該対戦相手が当該ユーザを標的として特定していることを判別可能とするための第３画像を含む前記表示用画像を逐次生成する、請求項１に記載のゲームプログラム。
3. 前記画像生成手段は、前記取得手段が取得した前記状況データに基づいて、複数の前記対戦相手それぞれの順位が判別可能な表示を含むように前記第２画像を生成して前記表示用画像に含める、請求項１または２に記載のゲームプログラム。
4. 前記画像生成手段は、
   前記対戦相手がゲームを続行できない状況となった場合、当該対戦相手がゲームを続行できない状況となった時点で確定した順位が判別可能な表示を含むように前記第２画像を生成して前記表示用画像に含める、請求項３に記載のゲームプログラム。
5. 前記取得手段は、前記ユーザのゲーム状況が前記ゲームの続行ができない状況となった後も前記状況データの逐次取得を継続し、
   前記画像生成手段は、前記ユーザのゲーム状況が前記ゲームの続行ができない状況となった後も、前記状況データに基づいて前記第２画像を含む表示用画像を逐次生成する、請求項１乃至４のいずれかに記載のゲームプログラム。
6. 前記画像生成手段は、第１領域に前記第１画像を配置し、第２領域に複数の前記第２画像のそれぞれを配置するように前記表示用画像を逐次生成する、請求項１乃至５のいずれかに記載のゲームプログラム。
7. 前記画像生成手段は、前記表示用画像の中央に位置する第１領域に前記第１画像を配置し、当該第１領域とは異なる位置となる第２領域に前記第２画像のそれぞれを配置するように前記表示用画像を逐次生成する、請求項６に記載のゲームプログラム。
8. 前記画像生成手段は、前記表示用画像の中央に位置する第１領域に前記第１画像を配置し、当該第１領域の左右となる位置に第２領域を１つずつ配置し、当該左右それぞれの第２領域に前記第２画像のそれぞれを配置するように前記表示用画像を逐次生成する、請求項６に記載のゲームプログラム。
9. 前記画像生成手段は、前記標的として特定した対戦相手のゲームのプレイ状況を示す前記状況データに基づいて生成される前記第２画像に標的用画像を重畳した表示用画像を逐次生成する、請求項１乃至８のいずれかに記載のゲームプログラム。
10. 前記対戦ゲームは、所定のプレイフィールド内において時間経過に応じて増加するパズルオブジェクトを消去するパズルゲームであり、
    前記変化指示手段は、前記特定手段によって標的として特定された対戦相手のパズルオブジェクトの数を増加させるための指示を行い、
    前記ゲームプログラムは、前記パズルオブジェクトのプレイフィールド内での配置状態が予め定義されている敗北条件を満たした場合、当該ゲームの続行ができないゲーム状況であると判定し、前記ユーザおよび複数の前記対戦相手の全員の中で最後まで当該敗北条件を満たさずに残った場合に勝利条件を満たしたと判定する勝敗判定手段として前記コンピュータを更に機能させる、請求項２に記載のゲームプログラム。
11. 前記ゲームプログラムは、前記ユーザが前記標的として特定している前記対戦相手にかかるゲーム状況が、当該ユーザの情報処理装置の前記変化指示手段が行った指示によって増加した前記パズルオブジェクトが原因となって前記敗北条件を満たした場合に、当該ユーザに関連づけられた敗北誘導数に所定値を加算する加算手段として前記コンピュータを更に機能させ、
    前記状況データには、前記対戦相手の敗北誘導数を示す敗北誘導数情報が含まれており、
    前記画像生成手段は、前記敗北誘導数情報に基づいて、前記対戦相手の有する敗北誘導数を示す情報が含まれる前記第２画像を生成する、請求項１０に記載のゲームプログラム。
12. 前記加算手段は、前記ユーザに関連づけられた前記敗北誘導数に所定値を加算するとき、前記敗北条件を満たした前記対戦相手が所持する敗北誘導数を加えた値を前記所定値として加算する、請求項１１に記載のゲームプログラム。
13. 前記特定手段は、前記方針選択手段によって選択されている方針が第１の方針の場合、前記敗北誘導数が最も大きい対戦相手を前記標的として特定する、請求項１２に記載のゲームプログラム。
14. 前記特定手段は、前記方針選択手段によって選択された方針が第２の方針の場合、前記被特定情報データに基づき、前記ユーザを標的として特定している対戦相手を、当該ユーザの標的として特定する、請求項１２に記載のゲームプログラム。
15. ユーザに対戦ゲームを提供するためのゲーム装置であって、
    当該ユーザの対戦相手に関連する第２ゲーム処理とは独立して進行する第１ゲーム処理を前記ユーザの操作に基づいて実行するゲーム実行手段と、
    複数の前記対戦相手に関連する前記第２ゲーム処理の第２ゲーム状況を示す状況データを逐次取得する取得手段と、
    前記第１ゲーム処理の第１ゲーム状況を反映した画像である第１画像と、前記取得手段によって取得した複数の前記状況データが示す前記第２ゲーム状況を反映した画像である複数の第２画像とを含む表示用画像を逐次生成する画像生成手段と、
    複数の前記対戦相手の中から少なくとも１を選択するための方針であって、予め設定されている複数の方針のうち、前記ユーザの操作に基づいていずれか１の方針を選択する方針選択手段と、
    前記選択された方針に基づいて、複数の前記対戦相手のうち、少なくとも１を標的として特定する特定手段と、
    前記ユーザのゲーム状況が所定の条件を満たす場合、前記特定手段によって標的として特定された対戦相手のゲーム状況を変化させるための指示を行う変化指示手段とを備える、ゲーム装置。
16. ユーザに対戦ゲームを提供するためのゲームシステムであって、
    当該ユーザの対戦相手に関連する第２ゲーム処理とは独立して進行する第１ゲーム処理を前記ユーザの操作に基づいて実行するゲーム実行手段と、
    複数の前記対戦相手に関連する前記第２ゲーム処理の第２ゲーム状況を示す状況データを逐次取得する取得手段と、
    前記第１ゲーム処理の第１ゲーム状況を反映した画像である第１画像と、前記取得手段によって取得した複数の前記状況データが示す前記第２ゲーム状況を反映した画像である複数の第２画像とを含む表示用画像を逐次生成する画像生成手段と、
    複数の前記対戦相手の中から少なくとも１を選択するための方針であって、予め設定されている複数の方針のうち、前記ユーザの操作に基づいていずれか１の方針を選択する方針選択手段と、
    前記選択された方針に基づいて、複数の前記対戦相手のうち、少なくとも１を標的として特定する特定手段と、
    前記ユーザのゲーム状況が所定の条件を満たす場合、前記特定手段によって標的として特定された対戦相手のゲーム状況を変化させるための指示を行う変化指示手段とを備える、ゲームシステム。
17. ユーザに対戦ゲームを提供するための情報処理装置に実行させるゲーム処理制御方法であって、
    当該ユーザの対戦相手に関連する第２ゲーム処理とは独立して進行する第１ゲーム処理を前記ユーザの操作に基づいて実行するゲーム実行ステップと、
    複数の前記対戦相手に関連する前記第２ゲーム処理の第２ゲーム状況を示す状況データを逐次取得する取得ステップと、
    前記第１ゲーム処理の第１ゲーム状況を反映した画像である第１画像と、前記取得ステップで取得した複数の前記状況データが示す前記第２ゲーム状況を反映した画像である複数の第２画像とを含む表示用画像を逐次生成する画像生成ステップと、
    複数の前記対戦相手の中から少なくとも１を選択するための方針であって、予め設定されている複数の方針のうち、前記ユーザの操作に基づいていずれか１の方針を選択する方針選択ステップと、
    前記選択された方針に基づいて、複数の前記対戦相手のうち、少なくとも１を標的として特定する特定ステップと、
    前記ユーザのゲーム状況が所定の条件を満たす場合、前記特定ステップにおいて標的として特定された対戦相手のゲーム状況を変化させるための指示を行う変化指示ステップとを実行させる、ゲーム処理制御方法。

Images