(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-08-21
(45)【発行日】2023-08-29
(54)【発明の名称】ゲームプログラム、ゲーム装置、ゲームシステム、およびゲーム処理制御方法
(51)【国際特許分類】
A63F 13/533 20140101AFI20230822BHJP
A63F 13/843 20140101ALI20230822BHJP
A63F 13/5372 20140101ALI20230822BHJP
A63F 13/798 20140101ALI20230822BHJP
A63F 13/80 20140101ALI20230822BHJP
A63F 13/69 20140101ALI20230822BHJP
【FI】
A63F13/533
A63F13/843
A63F13/5372
A63F13/798
A63F13/80 E
A63F13/69 500
(21)【出願番号】P 2020004622
(22)【出願日】2020-01-15
(62)【分割の表示】P 2019020978の分割
【原出願日】2019-02-07
【審査請求日】2021-12-06
(73)【特許権者】
【識別番号】000233778
【氏名又は名称】任天堂株式会社
(74)【代理人】
【識別番号】110001276
【氏名又は名称】弁理士法人小笠原特許事務所
(74)【代理人】
【識別番号】100130269
【氏名又は名称】石原 盛規
(72)【発明者】
【氏名】中田 隆一
(72)【発明者】
【氏名】伊藤 邦朗
【審査官】宇佐田 健二
(56)【参考文献】
【文献】特開2006-122215(JP,A)
【文献】特開2012-045177(JP,A)
【文献】特開2012-223371(JP,A)
【文献】特開2003-062353(JP,A)
【文献】特開2005-270649(JP,A)
【文献】“テトリス64”,「電撃NINTENDO64 1月号」,日本,メディアワークス Media Works,1999年01月01日,第4巻,第1号,p.88
(58)【調査した分野】(Int.Cl.,DB名)
A63F 13/00-13/98,9/24
(57)【特許請求の範囲】
【請求項1】
ユーザに対戦ゲームを提供するための情報処理装置のコンピュータにおいて実行されるゲームプログラムであって、前記コンピュータを、
当該ユーザの対戦相手に関連する第2ゲーム処理とは独立して進行する第1ゲーム処理を前記ユーザの操作に基づいて実行するゲーム実行手段と、
複数の前記対戦相手に関連する前記第2ゲーム処理の第2ゲーム状況を示す状況データを逐次取得する取得手段と、
前記第1ゲーム処理の第1ゲーム状況を反映した画像である第1画像と、前記取得手段によって取得した複数の前記状況データが示す前記第2ゲーム状況を反映した画像である複数の第2画像とを含む表示用画像を逐次生成する画像生成手段と、
前記対戦ゲームのプレイ中に、複数の前記対戦相手の中から少なくとも1を自動的に選択するための方針であって、予め設定されている複数の方針のうち、前記ユーザの操作に基づいていずれか1の方針を選択する方針選択手段と、
前記対戦ゲームのプレイ中に、前記選択された方針に基づいて、複数の前記対戦相手のうち、少なくとも1を標的として特定する特定手段と、
前記ユーザのゲーム状況が所定の条件を満たす場合、前記特定手段によって標的として特定された対戦相手のゲーム状況を変化させるための指示を行う変化指示手段として機能させる、ゲームプログラム。
【請求項2】
前記取得手段は、複数の前記対戦相手のそれぞれが前記ユーザを標的として特定しているか否かを示す被特定情報データを含む前記状況データを逐次取得し、
前記画像生成手段は、前記対戦相手が前記ユーザを標的として特定していることを前記被特定情報データが示す場合、当該対戦相手が当該ユーザを標的として特定していることを判別可能とするための第3画像を含む前記表示用画像を逐次生成する、請求項1に記載のゲームプログラム。
【請求項3】
前記画像生成手段は、前記取得手段が取得した前記状況データに基づいて、複数の前記対戦相手それぞれの順位が判別可能な表示を含むように前記第2画像を生成して前記表示用画像に含める、請求項1または2に記載のゲームプログラム。
【請求項4】
前記画像生成手段は、
前記対戦相手がゲームを続行できない状況となった場合、当該対戦相手がゲームを続行できない状況となった時点で確定した順位が判別可能な表示を含むように前記第2画像を生成して前記表示用画像に含める、請求項3に記載のゲームプログラム。
【請求項5】
前記取得手段は、前記ユーザのゲーム状況が前記ゲームの続行ができない状況となった後も前記状況データの逐次取得を継続し、
前記画像生成手段は、前記ユーザのゲーム状況が前記ゲームの続行ができない状況となった後も、前記状況データに基づいて前記第2画像を含む表示用画像を逐次生成する、請求項1乃至4のいずれかに記載のゲームプログラム。
【請求項6】
前記画像生成手段は、第1領域に前記第1画像を配置し、第2領域に複数の前記第2画像のそれぞれを配置するように前記表示用画像を逐次生成する、請求項1乃至5のいずれかに記載のゲームプログラム。
【請求項7】
前記画像生成手段は、前記表示用画像の中央に位置する第1領域に前記第1画像を配置し、当該第1領域とは異なる位置となる第2領域に前記第2画像のそれぞれを配置するように前記表示用画像を逐次生成する、請求項6に記載のゲームプログラム。
【請求項8】
前記画像生成手段は、前記表示用画像の中央に位置する第1領域に前記第1画像を配置し、当該第1領域の左右となる位置に第2領域を1つずつ配置し、当該左右それぞれの第2領域に前記第2画像のそれぞれを配置するように前記表示用画像を逐次生成する、請求項6に記載のゲームプログラム。
【請求項9】
前記画像生成手段は、ユーザが標的として特定している対戦相手を判別可能とするための標的用画像を含む表示用画像を逐次生成する、請求項2乃至8のいずれかに記載のゲームプログラム。
【請求項10】
前記ゲームプログラムは、前記ユーザが前記標的として特定している前記対戦相手にかかるゲーム状況が、当該ユーザの情報処理装置の前記変化指示手段が行った指示に基づいて
、予め定義されている敗北条件を満たした場合に、当該ユーザに関連づけられた敗北誘導数に所定値を加算する加算手段として前記コンピュータを更に機能させ、
前記状況データには、前記対戦相手の敗北誘導数を示す敗北誘導数情報が含まれており、
前記画像生成手段は、前記敗北誘導数情報に基づいて、前記対戦相手の有する敗北誘導数を示す情報が含まれる前記第2画像を生成する、請求項1乃至9のいずれかに記載のゲームプログラム。
【請求項11】
前記対戦ゲームは、所定のプレイフィールド内において時間経過に応じて増加するパズルオブジェクトを消去するパズルゲームであり、
前記変化指示手段は、前記特定手段によって標的として特定された対戦相手のパズルオブジェクトの数を増加させるための指示を行い、
前記ゲームプログラムは、前記パズルオブジェクトのプレイフィールド内での配置状態が予め定義されている敗北条件を満たした場合、当該ゲームの続行ができないゲーム状況であると判定し、前記ユーザおよび複数の前記対戦相手の全員の中で最後まで当該敗北条件を満たさずに残った場合に勝利条件を満たしたと判定する勝敗判定手段として前記コンピュータを更に機能させる、請求項2に記載のゲームプログラム。
【請求項12】
前記加算手段は、前記ユーザに関連づけられた前記敗北誘導数に所定値を加算するとき、前記敗北条件を満たした前記対戦相手が所持する敗北誘導数を加えた値を前記所定値として加算する、請求項1
0に記載のゲームプログラム。
【請求項13】
前記特定手段は、前記方針選択手段によって選択されている方針が第1の方針の場合、前記敗北誘導数が最も大きい対戦相手を前記標的として特定する、請求項1
0に記載のゲームプログラム。
【請求項14】
前記特定手段は、前記方針選択手段によって選択された方針が第2の方針の場合、前記被特定情報データに基づき、前記ユーザを標的として特定している対戦相手を、当該ユーザの標的として特定する、請求
項11に記載のゲームプログラム。
【請求項15】
前記選択された方針が第3の方針の場合、前記敗北条件に最も近い対戦相手を、当該ユーザの標的とする、請求項10または11に記載のゲームプログラム。
【請求項16】
前記複数の前記対戦相手のうち、前記選択された方針によらず、前記ユーザの指示に基づいて少なくとも1を前記標的とする、請求項1に記載のゲームプログラム。
【請求項17】
前記選択された方針が第4の方針の場合、ランダムで決定した対戦相手を、当該ユーザの標的とする、請求項1に記載のゲームプログラム。
【請求項18】
ユーザに対戦ゲームを提供するためのゲーム装置であって、
当該ユーザの対戦相手に関連する第2ゲーム処理とは独立して進行する第1ゲーム処理を前記ユーザの操作に基づいて実行するゲーム実行手段と、
複数の前記対戦相手に関連する前記第2ゲーム処理の第2ゲーム状況を示す状況データを逐次取得する取得手段と、
前記第1ゲーム処理の第1ゲーム状況を反映した画像である第1画像と、前記取得手段によって取得した複数の前記状況データが示す前記第2ゲーム状況を反映した画像である複数の第2画像とを含む表示用画像を逐次生成する画像生成手段と、
前記対戦ゲームのプレイ中に、複数の前記対戦相手の中から少なくとも1を自動的に選択するための方針であって、予め設定されている複数の方針のうち、前記ユーザの操作に基づいていずれか1の方針を選択する方針選択手段と、
前記対戦ゲームのプレイ中に、前記選択された方針に基づいて、複数の前記対戦相手のうち、少なくとも1を標的として特定する特定手段と、
前記ユーザのゲーム状況が所定の条件を満たす場合、前記特定手段によって標的として特定された対戦相手のゲーム状況を変化させるための指示を行う変化指示手段とを備える、ゲーム装置。
【請求項19】
ユーザに対戦ゲームを提供するためのゲームシステムであって、
当該ユーザの対戦相手に関連する第2ゲーム処理とは独立して進行する第1ゲーム処理を前記ユーザの操作に基づいて実行するゲーム実行手段と、
複数の前記対戦相手に関連する前記第2ゲーム処理の第2ゲーム状況を示す状況データを逐次取得する取得手段と、
前記第1ゲーム処理の第1ゲーム状況を反映した画像である第1画像と、前記取得手段によって取得した複数の前記状況データが示す前記第2ゲーム状況を反映した画像である複数の第2画像とを含む表示用画像を逐次生成する画像生成手段と、
前記対戦ゲームのプレイ中に、複数の前記対戦相手の中から少なくとも1を自動的に選択するための方針であって、予め設定されている複数の方針のうち、前記ユーザの操作に基づいていずれか1の方針を選択する方針選択手段と、
前記対戦ゲームのプレイ中に、前記選択された方針に基づいて、複数の前記対戦相手のうち、少なくとも1を標的として特定する特定手段と、
前記ユーザのゲーム状況が所定の条件を満たす場合、前記特定手段によって標的として特定された対戦相手のゲーム状況を変化させるための指示を行う変化指示手段とを備える、ゲームシステム。
【請求項20】
ユーザに対戦ゲームを提供するための情報処理装置に実行させるゲーム処理制御方法であって、
当該ユーザの対戦相手に関連する第2ゲーム処理とは独立して進行する第1ゲーム処理を前記ユーザの操作に基づいて実行するゲーム実行ステップと、
複数の前記対戦相手に関連する前記第2ゲーム処理の第2ゲーム状況を示す状況データを逐次取得する取得ステップと、
前記第1ゲーム処理の第1ゲーム状況を反映した画像である第1画像と、前記取得ステップで取得した複数の前記状況データが示す前記第2ゲーム状況を反映した画像である複数の第2画像とを含む表示用画像を逐次生成する画像生成ステップと、
前記対戦ゲームのプレイ中に、複数の前記対戦相手の中から少なくとも1を自動的に選択するための方針であって、予め設定されている複数の方針のうち、前記ユーザの操作に基づいていずれか1の方針を選択する方針選択ステップと、
前記対戦ゲームのプレイ中に、前記選択された方針に基づいて、複数の前記対戦相手のうち、少なくとも1を標的として特定する特定ステップと、
前記ユーザのゲーム状況が所定の条件を満たす場合、前記特定ステップにおいて標的として特定された対戦相手のゲーム状況を変化させるための指示を行う変化指示ステップとを実行させる、ゲーム処理制御方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、対戦ゲームにおけるゲーム処理に関し、より特定的には、攻撃対象とする対戦相手を特定する処理に関する。
【背景技術】
【0002】
従来から、いわゆる落ちものゲームで対戦するゲームが知られている(例えば特許文献1)。また、このゲームでは、プレイヤ2人で1チームを組み、2vs2でのチーム対戦が可能となっている。また、このゲームでは、第1のチーム内の一方のプレイヤが、他方のプレイヤのゲームフィールドの所定範囲に蓄積されたボールをブロックとして引き取ること可能となっている。また、これにより、蓄積されたボールがゲームフィールドの上端に到達することを回避できたり、一方のプレイヤが他方のプレイヤのボールを利用して、相手チームに対して攻撃を加えることができることも開示されている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかし、上記の技術においては、対戦相手となるチームは1つだけであるため、攻撃する相手を選択する余地は実質的に無い、あるいは乏しいものであった。言い換えれば、各プレイヤで独立してゲームが進行するゲームにおいて、攻撃の標的対象となる相手の選択方法が乏しかった。つまり、攻撃相手の選択という点での対戦ゲームの戦術に関する興趣性について改良する余地があった。
【0005】
それ故に、本発明の目的は、対戦ゲームの戦術に関する興趣性をより高めることが可能なゲームプログラム、ゲーム装置、ゲーム処理方法、ゲームシステムを提供することである。
【課題を解決するための手段】
【0006】
上記目的を達成するために、例えば以下のような構成例が挙げられる。
【0007】
構成例の一例は、ユーザに対戦ゲームを提供するための情報処理装置のコンピュータにおいて実行されるゲームプログラムであって、前記コンピュータを、ゲーム実行手段と、取得手段と、画像生成手段と、方針選択手段と、特定手段と、変化指示手段として機能させる。ゲーム実行手段は、当該ユーザの対戦相手に関連する第2ゲーム処理とは独立して進行する第1ゲーム処理をユーザの操作に基づいて実行する。取得手段は、複数の対戦相手に関連する第2ゲーム処理の第2ゲーム状況を示す状況データを逐次取得する。画像生成手段は、第1ゲーム処理の第1ゲーム状況を反映した画像である第1画像と、取得手段によって取得した複数の状況データが示す第2ゲーム状況を反映した画像である複数の第2画像とを含む表示用画像を逐次生成する。方針選択手段は、複数の対戦相手の中から少なくとも1を選択するための方針であって、予め設定されている複数の方針のうち、ユーザの操作に基づいていずれか1の方針を選択する。特定手段は、選択された方針に基づいて、複数の対戦相手のうち、少なくとも1を標的として特定する。変化指示手段は、ユーザのゲーム状況が所定の条件を満たす場合、特定手段によって標的として特定された対戦相手のゲーム状況を変化させるための指示を行う。
【0008】
上記構成例によれば、ユーザは対戦相手とは独立して進行するゲーム処理を行いながらも、複数の対戦相手のうちのどの対戦相手のゲーム状況を変化させるかについて、ユーザの選択した方針に基づいて選択することができるため、対戦ゲームの戦術に関する興趣性を向上させることができる。特に、多数の対戦相手から所定の対戦相手を選択したい場合に、ユーザの意思を反映した速やかな選択が可能となる。
【0009】
他の構成例として、取得手段は、複数の対戦相手のそれぞれがユーザを標的として特定しているか否かを示す被特定情報データを含む状況データを逐次取得し、画像生成手段は、対戦相手がユーザを標的として特定していることを被特定情報データが示す場合、当該対戦相手が当該ユーザを標的として特定していることを判別可能とするための第3画像を含む表示用画像を逐次生成してもよい。
【0010】
上記構成例によれば、ユーザがどの対戦相手から標的にされているのかを判別しやすくすることができ、ゲームの緊迫感を向上することできる。
【0011】
他の構成例として、画像生成手段は、取得手段が取得した状況データに基づいて、複数の対戦相手それぞれの順位が判別可能な表示を含むように第2画像を生成して表示用画像に含めるようにしてもよい。
【0012】
他の構成例として、画像生成手段は、対戦相手がゲームを続行できない状況となった場合、当該対戦相手がゲームを続行できない状況になった時点で確定した順位が判別可能な表示を含むように第2画像を生成して表示用画像に含めるようにしてもよい。
【0013】
上記構成例によれば、対戦相手の順位をユーザに把握させることができ、対戦ゲーム全体の進行状況を判別しやすくすることができる。
【0014】
他の構成例として、取得手段は、ユーザのゲーム状況がゲームの続行ができない状況となった後も状況データの逐次取得を継続してもよい。更に、画像生成手段は、ユーザのゲーム状況がゲームの続行ができない状況となった後も、状況データに基づいて第2画像を含む表示用画像を逐次生成してもよい。
【0015】
上記構成例によれば、ユーザは、自身が対戦ゲームに敗北した後も、対戦相手全員にかかるその後のゲーム状況を確認できる。これにより、ユーザがゲームに敗北した後でも、自身が参加した対戦ゲームのその後の状況・展開を楽しませることができる。
【0016】
他の構成例として、画像生成手段は、第1領域に第1画像を配置し、第2領域に複数の第2画像のそれぞれを配置するように表示用画像を逐次生成してもよい。
【0017】
上記構成例によれば、自身が進行させているゲームの状況に加えて、対戦相手のゲーム状況もユーザに提示できる。
【0018】
他の構成例として、画像生成手段は、表示用画像の中央に位置する第1領域に第1画像を配置し、当該第1領域とは異なる位置となる第2領域に第2画像のそれぞれを配置するように表示用画像を逐次生成してもよい。
【0019】
上記構成例によれば、ユーザが進行させているゲームの状況を、対戦相手が進行させているゲームの状況と判別しやすい態様でユーザに提示できる。
【0020】
他の構成例として、画像生成手段は、表示用画像の中央に位置する第1領域に第1画像
を配置し、当該第1領域の左右となる位置に第2領域を1つずつ配置し、左右それぞれの第2領域に第2画像のそれぞれを配置するように表示用画像を逐次生成してもよい。
【0021】
上記構成例によれば、ユーザ自身が進行させているゲームにかかるゲーム画像を中央に表示できる。そして、その左右それぞれに対戦相手のゲーム状況を示す画像を表示できる。これにより、自身のゲーム画像と対戦相手のゲーム状況を示す画像との間の視線の移動を最小限に抑えることができる。
【0022】
他の構成例として、画像生成手段は、標的として特定した対戦相手のゲームのプレイ状況を示す状況データに基づいて生成される第2画像に標的用画像を重畳した表示用画像(161)を逐次生成するようにしてもよい。
【0023】
上記構成例によれば、ユーザ自身が現在標的としている対戦相手を把握させやすくすることができる。
【0024】
他の構成例として、対戦ゲームは、所定のプレイフィールド内において時間経過に応じて増加するパズルオブジェクトを消去するパズルゲームであってもよい。更に、変化指示手段は、特定手段によって標的として特定された対戦相手のパズルオブジェクトの数を増加させるための指示を行ってもよい。そして、ゲームプログラムは、パズルオブジェクトのプレイフィールド内での配置状態が予め定義されている敗北条件を満たした場合、当該ゲームの続行ができないゲーム状況であると判定し、ユーザおよび複数の対戦相手の全員の中で最後まで当該敗北条件を満たさずに残った場合に勝利条件を満たしたと判定する勝敗判定手段としてコンピュータを更に機能させる構成であってもよい。
【0025】
上記構成例によれば、ユーザ自身のゲームを進行させながら適宜対戦相手のゲーム状況を変化させる指示を行い、敗北条件を満たさずに最後までプレイし続けることを目的とする対戦パズルゲームをユーザに提供できる。
【0026】
他の構成例として、ゲームプログラムは、前記ユーザが標的として特定している対戦相手にかかるゲーム状況が、当該ユーザの情報処理装置の変化指示手段が行った指示によって増加したパズルオブジェクトが原因となって敗北条件を満たした場合に、当該ユーザに関連づけられた敗北誘導数に所定値を加算する加算手段としてコンピュータを更に機能させてもよい。更に、状況データには、対戦相手の敗北誘導数を示す敗北誘導数情報が含まれていてもよく、画像生成手段は、敗北誘導数情報に基づいて、対戦相手の有する敗北誘導数を示す情報が含まれる第2画像を生成するようにしてもよい。
【0027】
上記構成例によれば、多くの対戦相手を敗北に導いたユーザが誰であるかを把握させやすくすることができる。
【0028】
他の構成例として、加算手段は、ユーザに関連づけられた敗北誘導数に所定値を加算するとき、敗北条件を満たした対戦相手が所持する敗北誘導数を加えた値を所定値として加算してもよい。
【0029】
上記構成例によれば、対戦ゲームの戦略性を高め、ゲームの興趣性を高めることができる。
【0030】
他の構成例として、特定手段は、方針選択手段によって選択されている方針が第1の方針の場合、敗北誘導数が最も大きい対戦相手を標的として特定してもよい。
【0031】
上記構成例によれば、敗北誘導数が多いユーザを標的とすることで、敗北誘導数を稼ぎ
やすくすることができる。
【0032】
他の構成例として、特定手段は、方針選択手段によって選択された方針が第2の方針の場合、被特定情報データに基づき、前記ユーザを標的として特定している対戦相手を当該ユーザの標的として特定してもよい。
【0033】
上記構成例によれば、自分を標的として設定している対戦相手を自身の標的として設定できる。これにより、多数の対戦相手から標的として狙われている場合、これらの対戦相手を標的として選択する操作を簡易なものにできる。また、ユーザにとって一方的に不利な状況になることを防ぎ、ゲームバランスを適度なものにすることができる。
【発明の効果】
【0034】
本実施形態によれば、多数の対戦相手から所定の対戦相手を選択したい場合に、ユーザの意思を反映した速やかな選択操作を行うことができる。
【図面の簡単な説明】
【0035】
【
図1】本実施形態に係る情報処理システムの全体像を示す模式図
【
図3】本体装置2の内部構成の一例を示すブロック図
【
図4】サーバ101の内部構成の一例を示すブロック図
【
図20】本体装置2の記憶部84に記憶される各種データの一例を示すメモリマップ
【
図24】待機ブロックデータ309のデータ構成の一例
【
図25】サーバ101の記憶部112に記憶される各種データの一例を示すメモリマップ
【
図26】サーバ101および各ゲームシステム1との協働による全体的な処理の流れを示す図
【
図30】ブロック消去関連処理の詳細を示すフローチャート
【
図31】お邪魔ブロック処理の詳細を示すフローチャート
【
図32】ゲームオーバー処理の詳細を示すフローチャート
【発明を実施するための形態】
【0036】
以下、本発明の一実施形態について説明する。
図1は、本実施形態に係る情報処理システムの全体像を示す模式図である。本実施形態の情報処理システム100は、サーバ101と、複数のゲームシステム1とを含んでいる。サーバ101と、各ゲームシステム1とは、インターネット103を介して通信可能に構成されている。
【0037】
上記のような構成で実行される情報処理の一例として、本実施形態では、ゲーム処理を例として説明する。具体的には、各ゲームシステム1において単独のユーザの操作に基づいて他のゲームシステム1とは独立して進行するゲーム処理が実行されつつ、サーバ101を介してゲームシステム1間で当該ゲーム処理に基づく所定のデータを送受信することで、多人数参加型の対戦型ゲームを実現するゲーム処理が実行される。
【0038】
次に、本実施形態にかかるゲームシステム1について説明する。このゲームシステムはどのようなものでもよいが、
図2に、一例として本例で用いるゲームシステムの外観図を示す。
図2で示すゲームシステム1は、本体装置(情報処理装置;本実施形態ではゲーム装置本体として機能する)2と左コントローラ3および右コントローラ4とを含む。本体装置2は、左コントローラ3および右コントローラ4がそれぞれ着脱可能である。つまり、ゲームシステム1は、左コントローラ3および右コントローラ4をそれぞれ本体装置2に装着して一体化された装置として利用できる。また、ゲームシステム1は、本体装置2と左コントローラ3および右コントローラ4とを別体として利用することもできる。なお、
図2は、本体装置2に左コントローラ3および右コントローラ4を装着した状態の一例を示す図である。
図2に示すように、左コントローラ3および右コントローラ4は、それぞれ本体装置2に装着されて一体化されている。本体装置2は、ゲームシステム1における各種の処理(例えば、ゲーム処理)を実行する装置である。本体装置2は、ディスプレイ12を備える。左コントローラ3および右コントローラ4は、ユーザが入力を行うための操作部を備える装置である。
【0039】
図3は、本体装置2の内部構成の一例を示すブロック図である。本体装置2は、プロセッサ81を備える。プロセッサ81は、本体装置2において実行される各種の情報処理を実行する情報処理部であって、例えば、CPU(Central Processing
Unit)のみから構成されてもよいし、CPU機能、GPU(Graphics Processing Unit)機能等の複数の機能を含むSoC(System-on-a-chip)から構成されてもよい。プロセッサ81は、記憶部84に記憶される情報処理プログラム(例えば、ゲームプログラム)を実行することによって、各種の情報処理を実行する。なお、記憶部84は、例えば、フラッシュメモリやDRAM(Dynamic Random Access Memory)等の内部記憶媒体であってもよいし、図示しないスロットに装着される外部記憶媒体等を利用する構成でもよい。
【0040】
本体装置2は、ネットワーク通信部82を備える。ネットワーク通信部82は、プロセッサ81に接続される。ネットワーク通信部82は、ネットワークを介して外部の装置と通信(具体的には、無線通信)を行う。本実施形態においては、ネットワーク通信部82は、第1の通信態様としてWi-Fiの規格に準拠した方式により、無線LANに接続して外部装置と通信を行う。また、ネットワーク通信部82は、第2の通信態様として所定の通信方式(例えば、独自プロトコルによる通信や、赤外線通信)により、同種の他の本体装置2との間で無線通信を行う。なお、上記第2の通信態様による無線通信は、閉ざされたローカルネットワークエリア内に配置された他の本体装置2との間で無線通信可能であり、複数の本体装置2の間で直接通信することによってデータが送受信される、いわゆ
る「ローカル通信」を可能とする機能を実現する。
【0041】
本体装置2は、コントローラ通信部83を備える。コントローラ通信部83は、プロセッサ81に接続される。コントローラ通信部83は、本体装置2と左コントローラ3および右コントローラ4とを別体として利用する場合において、左コントローラ3および/または右コントローラ4と無線通信を行う。本体装置2と左コントローラ3および右コントローラ4との通信方式は任意であるが、本実施形態においては、コントローラ通信部83は、左コントローラ3との間および右コントローラ4との間で、Bluetooth(登録商標)の規格に従った通信を行う。
【0042】
また、本体装置2は、本体装置2が左コントローラ3と有線通信を行うための端子である左側端子17と、本体装置2が右コントローラ4と有線通信を行うための右側端子21を備える。
【0043】
また、ディスプレイ12は、プロセッサ81に接続される。プロセッサ81は、(例えば、上記の情報処理の実行によって)生成した画像および/または外部から取得した画像をディスプレイ12に表示する。
【0044】
本体装置2は、コーデック回路87およびスピーカ(具体的には、左スピーカおよび右スピーカ)88を備える。コーデック回路87は、スピーカ88および音声入出力端子25に接続されるとともに、プロセッサ81に接続される。コーデック回路87は、スピーカ88および音声入出力端子25に対する音声データの入出力を制御する回路である。
【0045】
なお、図示は省略するが、本体装置2で生成された画像や音声については、所定の出力端子を介して、外部モニタ/外部スピーカに出力することも可能である。
【0046】
[コントローラについて]
また、図示は省略するが、左コントローラ3、右コントローラ4は、それぞれ、本体装置2との間で通信を行う通信制御部を備えている。本体装置2に左コントローラ3および右コントローラ4を装着した状態では、上記左側端子17および右側端子21を介した有線通信が可能である。また、本体装置2と左コントローラ3および右コントローラ4とを別体として利用する場合は、上記端子を介さない無線通信で本体装置2と通信を行うことが可能である。通信制御部は、コントローラの各入力部から、入力に関する情報(具体的には、操作に関する情報を取得する。そして、通信制御部は、取得した情報(または取得した情報に所定の加工を行った情報)を含む操作データを本体装置2へ送信する。なお、操作データは、所定時間に1回の割合で繰り返し送信される。なお、入力に関する情報が本体装置2へ送信される間隔は、各入力部について同じであってもよいし、同じでなくてもよい。
【0047】
[サーバのハードウェア構成]
次に、上記サーバ101の構成について説明する。
図4は、サーバ101の内部構成の一例を示すブロック図である。サーバ101は、プロセッサ111と、記憶部112と、通信部113とを少なくとも備えている。プロセッサ111は、サーバ101を制御するための各種プログラムを実行する。記憶部112には、プロセッサ111によって実行される各種プログラムおよび利用される各種データが格納される。通信部113は、有線、または無線通信によってインターネット103と接続し、上記ゲームシステム1との間で所定のデータを送受信する。
【0048】
[ゲーム処理の概要]
次に、本実施形態で実行されるゲーム処理の概要について説明する。本実施形態では、
ゲーム処理の一例として、時間経過に応じて増加する「パズルオブジェクト」を消去するパズルゲーム処理が実行される。具体的には、本実施形態では、2次元のプレイフィールドにおいて、上から時間経過に応じて1つずつ落下してくるパズルオブジェクトを移動・回転させて積み上げていき、所定の条件を満たすことで当該積み上げたパズルオブジェクトの少なくとも一部を消去するというアクションパズルゲーム処理が実行される(「落ちものパズル」とも呼ばれるゲーム処理である)。当該パズルオブジェクトとしては、例えば格子状のブロックや、カプセル形状のピースや、所定の形状のパネル等である。また、当該所定の条件としては、例えば、横1行を全てブロックで埋めること、同じ色のパネルを所定方向に所定数以上揃えること、同じ柄のパネルを所定数以上揃えること、同じ形状のピースを所定数以上揃えること、同色のブロックで所定の形状(正方形など)を作ること、等である。本実施形態では、プレイフィールドとして、縦20×横10マス分のプレイフィールドを想定し、パズルオブジェクトとして様々な形状を構成しているブロック群が落下するものを例とする。また、所定条件として、プレイフィールドの横1行分がブロックで埋まると、そのブロックが消去される場合を例として説明する。例えば、各ユーザは、当該プレイフィールド1511の上部から落下してくるブロック群を左右方向、あるいは下方向に移動させ、また、当該ブロック群を回転させる操作を行う。そして、プレイフィールドの最下段または既に積み上がっている他のブロックの上に落下させることで、当該ブロックの位置を固定できる。その結果、横1行分がブロックで埋まっていれば、当該横1行分のブロックが消去される。また、プレイフィールドの最上段までブロックが積み上がると、ゲームオーバーとなる。
【0049】
また、本実施形態にかかるパズルゲーム処理として、最大で99人のユーザで対戦できるゲーム処理を想定する。この対戦の概要について説明する。まず、当該対戦の勝利条件としては、「99人の中でゲームオーバーにならないまま最後まで残る」ことである。そして、本ゲームでは、各ユーザが個々にパズルゲームを進行させつつ、所定の他のユーザに後述する「お邪魔ブロック」を送り込むことでゲーム進行を妨害できる。このように、ユーザは、他のユーザのゲーム進行の妨害を試みながら各自のパズルゲームを進行させ、ゲームオーバーにならずに最後までプレイし続けることを目指すものである。なお、以下の説明では、このような他のユーザに「お邪魔ブロック」を送り込むことを、他のユーザへの「攻撃」と呼ぶ。
【0050】
より具体的に説明すると、各ゲームシステム1のディスプレイ12には、表示用画像の一例である、
図5に示すようなゲーム画像がそれぞれ表示される。当該ゲーム画像の構成要素の詳細は後述するが、各ユーザは、後述のプレイフィールド1511に対してパズルゲームに係る操作を行い、ユーザ毎に個別にパズルゲーム処理を進行させていく。換言すれば、基本的には、各ユーザにかかるプレイフィールドに対しては、各ユーザが各自のコントローラを操作することで生成された操作データの内容のみが反映される。つまり、他のユーザが操作したコントローラにかかる操作データが直接的に反映されるようなオブジェクト等はプレイフィールド内に存在しない。例えば、対戦格闘ゲームやレースゲームのような、同じステージや同じゲームフィールド内に複数のユーザがそれぞれ操作するキャラクタ等が存在し、各ユーザの操作が反映されるという対戦ゲームではないということである。そして、本ゲームでは、上記ブロックを消去したときに、そのときに「標的」として設定されている他のユーザに対して、上記の「お邪魔ブロック」と呼ばれる特殊なブロックを送り込むことで、他のユーザを攻撃できる。また、逆に他のユーザから「お邪魔ブロック」を送り込まれることもあり得る。つまり、他のユーザから攻撃を受けることもあり得る。そして、本実施形態では、当該「お邪魔ブロック」に関するデータや各ユーザのプレイフィールド状況を示すデータを他のユーザ間と送受信する。これにより、各ゲームシステム1において個別にパズルゲームを進行させながら、上記送受信されるデータに基づいて、他のユーザのプレイフィールドの状況等を反映した画像も表示し、他のユーザの状況も把握できるようにしている。また、ユーザ間で行われる「攻撃」も反映させている
。つまり、各ゲームシステム1で独立してパズルゲーム処理を進行させながらも、上記送受信されるデータを用いてゲームシステム1間でゲーム処理を連動させることで、本実施形態にかかる対戦ゲーム処理を実現している。
【0051】
[ゲーム画像例]
次に、本パズルゲーム処理におけるゲーム画像の構成要素、およびそれに伴うユーザの操作やギミックに関して説明する。
図5は、各ゲームシステム1のディスプレイ12に表示される本パズルゲームのゲーム画像の一例である。
図5では、第1領域151と、第2領域152L、第2領域152R(以下では総称して第2領域152と呼ぶこともある)とが示されている。第1領域151は、ゲーム画像の略中央に配置されており、その左側に第2領域152Lが配置されている。また、第1領域151の右側に第2領域152Rが配置されている。第1領域151には、主に当該ゲームシステム1のユーザの操作によって進行するパズルゲームに関する各種画像が表示される。第2領域152L、152Rには、他のユーザがプレイしているパズルゲームのプレイフィールドの状況を示す画像が表示される。なお、以下の説明では、当該他のユーザのことを「対戦相手」と呼ぶ。
【0052】
次に、第1領域151の詳細について説明する。
図6は、上記第1領域151を拡大して示した図である。
図6において、第1領域151には、プレイフィールド1511、待機ブロック領域1512、ネクストブロック領域1513、バッジ表示領域1514が表示される。また、プレイフィールド1511の上端付近には、作戦操作パネル1515も表示されている。
【0053】
プレイフィールド1511は、横10マス×縦20マスからなる2次元のフィールドであり、本パズルゲームのメインとなる部分でもある。当該プレイフィールド1511の上方から上記ブロック群が下方に向かって落下する。上記のようにユーザはプレイフィールド1511内で当該ブロック群を左右に移動させたり、回転させたりする操作ができる。そして、積み上げた横1行分が埋まったブロックを消去することができる。なお、
図6では各マス目を点線で区切って示しているが、実際のゲーム画像では、このようなマス目を示す線は表示されていてもよいし、表示されなくてもよい。
【0054】
次に、待機ブロック領域1512は、対戦相手から送り込まれた「お邪魔ブロック」に関する情報を表示するための領域である。この領域の表示内容に関しては、後ほど「お邪魔ブロック」の説明と併せて説明する。
【0055】
ネクストブロック領域1513は、今後落下予定のブロック群について提示するための領域である。なお、本ゲームにおいては、様々な形状のブロックが1つずつ落下してくるが、これらブロックが落下する順番については、99人のユーザ全てについて同じ順番であるものとする。
【0056】
バッジ表示領域1514は、当該ユーザが獲得した「バッジ」を表示するための領域である。当該「バッジ」は、当該ユーザが送り込んだ「お邪魔ブロック」が原因でゲームオーバーになった対戦相手の数(いわば、当該ユーザがとどめをさした対戦相手の数)を示すものである。当該「バッジ」の詳細については後述する。
【0057】
作戦操作パネル1515は、「作戦」を選択するための操作パネルである。詳細は後述するが、「作戦」とは、攻撃対象とする(お邪魔ブロックを送り込む)対戦相手(以下、標的と呼ぶ)の選択方針の一例である。プロセッサ81は、そのときに選択されている作戦に基づいて、98人の対戦相手の中から所定のユーザを「標的」として設定する。なお、本実施形態では、当該作戦の選択操作として、右コントローラ4が備えるアナログスティックを用いる。当該アナログスティックを上下左右方向に傾けることで、各方向に対応
した4つの作戦のうちの1つが選択されるものとする。
図6では、作戦操作パネル1515の略中央にアナログスティックを模した円の画像が表示され、その上下左右となる方向にそれぞれ、作戦名を示す選択肢画像が表示されている。このような構成で、ユーザのパズルゲーム操作(ブロックの移動や回転操作)を極力邪魔することなく、作戦の選択操作を速やかに行うことが可能となっている。
【0058】
次に、
図5で示した第2領域152Lおよび152Rについて説明する。上記のように、第2領域152Lは第1領域151の左側に配置され、第2領域152Rは第1領域151の右側に配置されている。第2領域152Lには、98人の対戦相手のうちの49人分の対戦相手のプレイフィールドの状況を示す49個の対戦相手画像1521が、7×7の配列で表示される。また、第2領域152Rには、残り49人分の対戦相手のプレイフィールド1511の状況を示す49個の対戦相手画像1521が、同様に7×7の配列で表示される。
【0059】
[攻撃について]
次に、対戦相手に対する攻撃、すなわち、「お邪魔ブロック」の送り込みに関して説明する。この「お邪魔ブロック」は、対戦相手のプレイフィールドの状況に変化を及ぼす要素の一例である。以下に説明するような「お邪魔ブロック」の送り込みによって、戦術性の高い対戦ゲームを提供することができる。
【0060】
まず、自分が対戦相手に対して攻撃する場合に関して説明する。本ゲームでは、まず、「お邪魔ブロック」を送り込む相手、すなわち、上記「標的」を決める必要がある。この「標的」は、後述する「作戦」に応じてプロセッサ81が設定するが、原則として、「標的」として設定できる相手は1人だけである。但し、後述する「作戦」のうちの「カウンター狙い」の場合は、複数の対戦相手を「標的」として設定可能である。そして、「標的」として設定された対戦相手にかかる対戦相手画像1521には、
図7に示すように、これに重畳するようにして標的画像161が表示される。これにより、そのユーザを「標的」としているのかをユーザに把握させやすくすることができる。
【0061】
次に、自分が他のユーザの「標的」にされている場合のゲーム画像の表示に関して説明する。この場合は、
図8に示すように、プレイフィールド1511の下部に「CAUTION」パネル162が表示される。さらに、自分を「標的」としている対戦相手にかかる対戦相手画像1521(の中点)と当該「CAUTION」パネル162とを結ぶ直線163も表示される。また、自分を「標的」としている対戦相手にかかる対戦相手画像1521についても、太枠で囲まれたような表示態様に変化している。このような表示を行うことで、特に本実施形態で想定するような多数の対戦相手が存在するゲームにおいて、自分が対戦相手の「標的」にされている場合に、どのユーザが自分を「標的」としているのか、何人の対戦相手から「標的」とされているのか、等を容易に把握することが可能となる。なお、このような「標的」にされていることを示す手法については、本例のような「CAUTION」パネル162と直線163とを利用した画像の表示に限るものではない。対戦相手がユーザを「標的」として特定していることを判別可能とする目的が達成できるのであれば、どのような画像や表示態様を用いてもよい。
【0062】
なお、上記標的とする対戦相手や、標的にされている対戦相手については、後述の「作戦」に応じて刻々と変化する。そのため、特に「作戦」を変更しなくても、標的画像161や上記直線163の表示位置は刻々と変化し得る。
【0063】
上記のように、「標的」を設定した状態で、ユーザがブロックを消去した場合、その消去した内容(具体的には消去した行数)に応じた「お邪魔ブロック」を「標的」としている対戦相手に送り込むことができる。また、逆に、自分を「標的」としている対戦相手か
ら「お邪魔ブロック」が送り込まれることもある。以下、他のユーザから「お邪魔ブロック」を送り込まれた場合の動作に関して
図9~
図12を用いて説明する。
【0064】
図9は、第1領域151を拡大した図である。この図では、プレイフィールド1511に、縦2×横9のブロック群172が積み上がっている状態を示す。また、待機ブロック領域1512には、1つのブロック画像171が表示されている。このブロック画像171は、対戦相手から送り込まれたお邪魔ブロックを示す画像である。本ゲームでは、対戦相手からお邪魔ブロックが送り込まれた場合、一旦待機ブロック領域1512に上記ブロック画像171が表示される。その後、所定の待機時間だけ待機した後に、プレイフィールドに当該ブロック画像171に対応するお邪魔ブロックがプレイフィールド1511の下方から出現する(せり上がってくる)。以下の説明では、上記待機中のお邪魔ブロックのことを「待機中ブロック」と呼び、上記ブロック画像171は「待機ブロック画像」と呼ぶ。
【0065】
次に、
図10は、上記待機時間が経過して、お邪魔ブロック173がプレイフィールド1511に出現した状態を示す図である。
図10では、プレイフィールド1511の一番下の行に、左から4マス目を除いた9マスを埋めているお邪魔ブロック173が表示されている。ここで、本実施形態では、お邪魔ブロック173の内容として、横1行分のうちいずれか1マスだけランダムで空白にした9個分のブロックがお邪魔ブロック173として生成されるものとする。また、お邪魔ブロック173の出現に伴って、対応する待機ブロック画像171は待機ブロック領域1512から消去される。
【0066】
ここで、待機ブロック領域1512に表示される待機ブロック画像171の個数は、出現するお邪魔ブロック173の行数に対応する。
図9および
図10の例では、待機ブロック画像171は1個だけであったため、お邪魔ブロック173も1行分だけ出現している。この点、例えば、
図11に示すように、待機ブロック画像171が3個表示されている場合は、
図12に示すように、3行分のお邪魔ブロック173が出現する。
【0067】
[相殺について]
次に、お邪魔ブロックの「相殺」について説明する。上記のように待機ブロック領域1512に待機ブロック画像171が表示されている間にユーザがプレイフィールド1511内でブロックを消去することで、その消去した行数に応じて待機中ブロック画像171を消去することができる。つまり、待機中ブロックが存在している場合、ユーザがブロックを消去することで、当該待機中ブロックを相殺できる。例えば、待機ブロックが1個存在する場合に、ユーザが3行分のブロックを消去した場合、消去した3行分のうち1行分と当該1個の待機ブロックとが相殺される。その結果、当該待機ブロックはなくなる。また、そのときにユーザが「標的」にしている他ユーザに対しては、残り2行分の消去に基づいてお邪魔ブロックの送り込みが行われる。また、別の例として、待機ブロックが5個存在しており、ユーザが3行分のブロックを消去した場合は、この3行分の消去で3個の待機中ブロックが相殺される。その結果、待機中ブロックの数が2個となる。このように、自分に送り込まれたお邪魔ブロックを出現させないようにすることを可能とすることで、ゲームの戦略性を高めている。
【0068】
[バッジについて]
次に、対戦相手を敗北に誘導した数を示す情報を示す構成の一例である、上記「バッジ」に関して説明する。本ゲームでは、ゲームフィールドの上端までブロックが積み上がるとゲームオーバーとなる。そして、上記お邪魔ブロックはゲームフィールドの下方からせり上がるようにして出現する。そのため、お邪魔ブロックの出現が契機となってブロックがゲームフィールドの上端まで到達し、ゲームオーバーとなることもあり得る。本ゲームでは、ユーザが「標的」に送り込んだお邪魔ブロックの出現によってその「標的」がゲー
ムオーバーになった場合、バッジを一つ獲得できる。換言すれば、自分の攻撃によって「標的」にとどめをさした場合に、バッジを一つ獲得できる。また、当該バッジは、対戦相手を敗北に誘導した数を示す情報であるともいえる。このようにして獲得したバッジの数を示す情報は上記バッジ表示領域1514に表示される。
図13は、バッジに関する情報を示しているゲーム画像の一例である。
図13では、バッジ表示領域1514に3つのバッジ画像181が表示されている。つまり、ユーザは3つのバッジを獲得していることが示されている。なお、他の実施形態では、対戦相手を敗北に誘導した数を示す情報として、本例のようなバッジ以外の構成を用いてもよい。
【0069】
また、本ゲームでは、他ユーザが所持しているバッジ数の情報も対戦相手画像1521において表示される。上記
図13における第2領域152Lを拡大したものを
図14として示す。
図14では、対戦相手画像1521Aにおいて、左上端付近に1つのバッジ画像181が表示されている、また、対戦相手画像1521Bでは、左上端付近に2つのバッジ画像181が表示されている。これは、対戦相手画像1521Aにかかるユーザはバッジを1つ所持していることを示し、対戦相手画像1521Bにかかるユーザはバッジを2つ所持していることを示している。そして、このように、既にバッジを所持している対戦相手をゲームオーバーに追い込んだ場合は、上記のようにバッジを1つ獲得すると共に、当該相手が所持しているバッジをも獲得することができる。例えば2つのバッジを所持している対戦相手をゲームオーバーに追い込んだ場合は、1+2個の、合計3個のバッジを獲得できる。
【0070】
また、本ゲームでは、バッジの所持数に応じて、出現させる上記お邪魔ブロック173の行数を変化させることができる。以下では、出現させるお邪魔ブロック173の行数(換言すれば、上記待機ブロック数)のことを「攻撃力」と呼ぶ。本例では、例えば、攻撃力が”1”で、1行のお邪魔ブロック173を出現させることができるものとする。そして、ユーザが実際に消去した行数に応じた攻撃力(以下では基礎攻撃力と呼ぶ)に、バッジの所持数に応じた攻撃力が加算されることで、最終的に対戦相手のプレイフィールド1511に出現させるお邪魔ブロック173の行数が決まる。一例として、ユーザが1行分のブロックを消去した場合を想定する。この場合、基礎攻撃力は”1”である。このような場合で、このような場合で、バッジを1~2個所持しているときは、攻撃力が”1”加算され、最終的な攻撃力としては”2”となる。その結果、対戦相手のプレイフィールドには2行分のお邪魔ブロック173を出現させることができる。また、例えば、バッジを3~4個所持しているときは、攻撃力が”2”加算され、最終的な攻撃力としては”3”となる。また、例えばバッジを5~6個所持しているときは、攻撃力が”3”加算され、最終的な攻撃力としては”4”となる。このように、バッジを多く所持していれば「攻撃力」を高めることができ、「バッジの奪い合い」という要素を導入してゲームの興趣性を高めることができる。
【0071】
[ピンチ状態について]
ところで、本ゲームでは、積み上がったブロックがプレイフィールド1511の上5行分のマスのいずれかに到達した場合、ゲームオーバーになる危険性が高い状態とである「ピンチ状態」として扱われる。ユーザが「ピンチ状態」になった場合は、例えばプレイフィールド1511を赤枠で囲む等、ピンチ状態であることを示すような表示態様の変化が行われる。また、対戦相手が「ピンチ状態」になった場合は、例えばそのユーザに係る対戦相手画像1521を点滅表示させる等、そのユーザが「ピンチ状態」であることを示すように対戦相手画像1521の表示態様を変化させる。「ピンチ状態」にある対戦相手の存在をユーザに把握させやすくすることができる。また、自分が「ピンチ状態」であることを認識させやすくすることができる。
【0072】
[作戦について]
次に、上述した作戦に関して説明する。本ゲームにおいて、作戦は、ゲームオーバーとなっていない対戦相手の中から「標的」を決定する方針として用いられる。まず、当該作戦の意義について説明する。本ゲームは、99人という大人数で対戦するものであり、自分以外に98人もの対戦相手が存在する状態となる。また、本ゲームでは上記のように「標的」を選択する必要性がある。この「標的」の選択方法として、例えば上記第2領域152に表示される合計98個の対戦相手画像の中から任意の1つをユーザが直接的に選択する操作を行わせる、ということも考えられる。例えば選択用のカーソルを移動させたり、タッチパネル画面を用いている場合であればタッチ操作を行わせたりする、等である。しかし、本ゲームのようなアクションパズルゲームでは、その操作にある程度リアルタイム性が求められるため、落下するブロックの操作と並行してこのような多数の中から「標的」とする相手を吟味し、選択する操作を行うことは困難であると考えられる。そこで、本実施形態では、「標的」を選択するための方針である作戦をユーザに提示し、パズルゲームの操作と併用可能な簡易な操作でこの作戦が選択可能なように構成している。そして、実際の「標的」の選択については、選択中の作戦に基づいてプロセッサ81が所定の対戦相手を選択し、「標的」として設定する処理を実行する。
【0073】
次に、本ゲームで定義されている作戦の例を示す。本ゲームでは、以下の4つの作戦が選択可能なようにユーザに提示される。なお、これらの作戦名を示す文字列は、
図6で示した上記作戦操作パネル1515の上記選択肢画像において表示されているものとする。
作戦1:とどめ狙い
作戦2:ランダム
作戦3:バッジ狙い
作戦4:カウンター
以下、各作戦について説明する。
【0074】
[作戦1:とどめ狙い]
この作戦は、上記「ピンチ状態」となっている対戦相手を「標的」とする方針の作戦である。ユーザがこの作戦を選択すると、「ピンチ状態」の対戦相手が「標的」として選択される。つまり、ゲームオーバーに追い込みやすそうな対戦相手を狙う作戦といえる。「ピンチ状態」の対戦相手が複数いる場合は、例えば一番多くブロックが積み上がっている対戦相手が「標的」として選択されてもよい。あるいは、「ピンチ状態」の複数の対戦相手の中から1人をランダム選択するようにしてもよい。
【0075】
[作戦2:ランダム]
この作戦は、ゲームオーバーとなっていない対戦相手の中から1人のユーザをランダムで選択して「標的」に設定する作戦である。本ゲームでは、ゲーム開始直後はこの作戦がデフォルトで選択されているものとする。
【0076】
[作戦3:バッジ狙い]
この作戦は、ゲームオーバーとなっていない対戦相手の中で、最も多く上記バッジを所持している対戦相手を「標的」に設定する作戦である。
図15に、当該「バッジ狙い」作戦を選択している場合のゲーム画像例を示す。
図15では、この時点で最もバッジを多く所持している対戦相手画像1521Bに標的画像161が重畳表示されている。つまり、対戦相手画像1521Bにかかる対戦相手を「標的」としている状態である。上述のように、自分がとどめを刺した場合、その「標的」が所持するバッジも獲得できる。そして、バッジを多く所持していれば、お邪魔ブロック173を送り込むときの「攻撃力」を高めることができるため、バッジの数を積極的に増やしたい場合に有効な作戦といえる。
【0077】
[作戦4:カウンター]
この作戦は、自分を「標的」にしている対戦相手を「標的」として設定する作戦である
。また。自分を「標的」にしている対戦相手が複数いれば、その全員を「標的」として設定する。上記のように、本ゲームでは「標的」は原則として1人ではあるが、当該「カウンター」作戦については、複数の「標的」を設定可能となっている。
図16に、当該「カウンター」作戦を選択している場合のゲーム画像例を示す。
図16では、4人の対戦相手から自分が「標的」に設定されている状態である。そして、「カウンター」作戦によって、これら4人の対戦相手を「標的」として設定し、それぞれに対応する対戦相手画像1521に標的画像161を重畳表示している状態となっている。また、「カウンター」作戦を選択している状態において、自分を「標的」とする対戦相手の数が変動すれば、それに伴って、「標的」とする相手および標的画像161の表示位置も適宜変更されることになる。
【0078】
また、「カウンター」作戦を選択している場合、上記バッジ数に応じた攻撃力の変化とは別に、自分を「標的」にしている対戦相手の数に応じて攻撃力を変化させるようにしてもよい。例えば、自分を「標的」としている対戦相手数が多いほど、これらの対戦相手にお邪魔ブロックを送り込むときの攻撃力が更に高くなるようにしてもよい。一例を挙げると、上記基礎攻撃力が”1”でバッジの所持数が0個の場合を想定する。この場合、「カウンター」作戦の要素を考慮しなければ、最終的な攻撃力は”1”となる。このような場合で、「カウンター」作戦を選択し、自分を「標的」に設定している(=自分が「標的」にも設定しかえしている)対戦相手が1~3人であれば、例えば攻撃力に更に”1”が加算され、「カウンター」作戦における最終的な攻撃力は”2”となる。また、当該対戦相手が4~6人であれば、例えば攻撃力に更に”2”が加算され、「カウンター」作戦における最終的な攻撃力は”3”となる。また、例えば基礎攻撃力が”1”、バッジによる加算値が”1”である場合、「カウンター」作戦中の「標的」数が1~3人であれば、最終的な攻撃力は”3”となり、「標的」数が4~6人であれば、最終的な攻撃力は”4”となる。つまり、バッジ所持数に基づく攻撃力加算とは別枠で、「カウンター」作戦による攻撃力の加算が行われる。これにより、より多くの対戦相手から狙われているほど自分の攻撃力を高めて反撃することができ、ゲームの興趣性を高めることができる。特に、バッジの所持数が多い場合、より多くの対戦相手から狙われやすくなる可能性が高くなる。この場合に、「カウンター」作戦を選択しておくことで、一度に多数の対戦相手に対して、よりたくさんのお邪魔ブロックを送り込むことができ、一方的に不利な展開とはならないようにしてゲームの興趣性を高めることができる。
【0079】
なお、「作戦」については上記に限るものではなく、他の実施形態では、例えば以下のような「作戦」を選択可能なようにユーザに提示するようにしてもよい。
[出る杭討ち]:自分に対する攻撃頻度の高い対戦相手を優先して「標的」とする。
[タイマン討ち]:同じく「タイマン討ち」を選択している対戦相手とどちらかがゲームオーバーになるまで、1対1で勝負する。この場合、他の対戦相手からの攻撃は受けない状態となる。
[ピンポイント討ち]:ランダムで選択された1人の対戦相手を固定的に「標的」とする。つまり、この作戦を選択している間は、「標的」が1人に固定される。
[鉄壁ガード]:ブロックを消去した際、お邪魔ブロック173の送りこみは行わずに、上述した「相殺」に用いるためにストックしておく作戦。
【0080】
なお、他の実施形態では、上記のような「作戦」の指定によって標的を設定する操作方法と、ユーザが直接的に「標的」を指定する操作方法(例えば99個の対戦相手画像1521のうちの一つをユーザがタップしたり、カーソルを合わせて所定のボタンを押したりする等)とを併用可能なように構成してもよい。これにより、「作戦」(「標的」を決定する方針)を選択操作で半自動的に「標的」を決定できることに加え、ユーザが直接「標的」とする対戦相手を決定することもできるため、「標的」の決定に関して、よりユーザの意思を反映させやすくすることができる。
【0081】
[ゲームオーバー後にユーザができることについて]
次に、ゲームオーバーとなった場合の処理に関して説明する。本ゲームでは、各ユーザがゲームオーバーになった場合、ゲームを終了してゲーム画像の表示を終わらせることもできるが、対戦相手同士の対戦を「観戦」することも可能である。例えば、ゲームオーバーになったときに、ユーザに対して、この後観戦するか否かの問い合わせが行われる。これに対してユーザが観戦することを選べば、今回プレイした対戦ゲームが終了するまで(最後の1人が確定するまで)、ゲーム画像は表示され続ける。すなわち、ゲームオーバー後も、対戦相手のゲーム状況を示すデータをサーバ101から取得し続ける。この場合、第1領域151の表示内容については、ゲームオーバー時の内容が表示されたままとなり、第2領域152については、その後の対戦ゲームの状況に応じてその表示内容が変化することになる。なお、このようにゲームオーバー後に観戦している状態のことを「観戦モード」と呼ぶ。
【0082】
ここで、
図17および
図18を用いて、対戦相手がゲームオーバーになった後の第2領域152の表示に関して説明する。
図17は、第2領域152Lの一番左上の対戦相手画像1521Aにかかる対戦相手が最初にゲームオーバーになった状態を示す図である。
図17では、対戦相手画像1521Aとして、「KO」の文字を含む画像(ゲームオーバーとなったことを示す画像)と、その下に順位を示す数値とが表示されている。この図では、99人対戦において最初にゲームオーバーとなったため、「99位」が確定したことを示している。
【0083】
次に、
図18は、
図17の状態の後に、第2領域152Rの一番右上の対戦相手画像1521Bにかかる対戦相手が2番目にゲームオーバーになった状態を示す図である。2番目にゲームオーバーとなったため、順位として「98位」が確定したことになる。また、対戦相手画像1521Bでは、「KO」の画像と順位を示す数値との間に、「Watch」の文字列も表示されている。当該「Watch」の文字列は、その対戦相手が観戦モードであることを示すものである。つまり、
図18の状態では、対戦相手画像1521Aにかかる対戦相手は、ゲームオーバー後、観戦せずに対戦ゲームを終了しているが、対戦相手画像1521Bにかかる対戦相手は、ゲームオーバー後、観戦している状態であることを示している。このように、第2領域152には、対戦相手がゲームオーバーになった場合は、そのことを示す画像と順位が表示される。また、当該ゲームオーバーになった対戦相手が観戦することを選択した場合は、そのことを示す表示(上記例では「Watch」の文字列の表示)も行われる。これにより、どの対戦相手がゲームオーバーになっているかについて把握しやすくすることできる。また、観戦モードの対戦相手がどの程度存在しているかについても把握しやすくすることができる。
【0084】
上記説明した標的画像161、「CAUTION」パネル162、直線163、バッジ画像181、待機ブロック画像171や「KO」の画像等の各表示要素は、言うまでもないが、実際のゲーム画像では同時に表示され得る。
図19に、これらの表示要素が同時に表示されているゲーム画像の例を示す。実際のゲームプレイでは、このような表示で、標的画像161および直線163の表示位置や、バッジ画像181および待機ブロック画像171の数等が刻々と変化しながら、ゲームが進行するものである。
【0085】
このように、本実施形態にかかる対戦ゲームでは、98人という多数の対戦相手から「標的」を選ぶために、ユーザに作戦を選択させ、これに基づいてプロセッサ81が「標的」を設定している。これにより、どの対戦相手のゲーム状況(本例ではプレイフィールド1511の状況)に変化を与えるかについて、ユーザのゲーム操作を邪魔することなく、ユーザの意思をより反映させた決定を行うことが可能となる。
【0086】
[本実施形態のゲーム処理の詳細]
次に、
図20~
図33を参照して、本実施形態におけるゲーム処理についてより詳細に説明する。
【0087】
[使用データについて]
まず、本ゲーム処理にて用いられる各種データに関して説明する。
図20は、本体装置2の記憶部84に記憶される各種データの一例を示すメモリマップである。本体装置2の記憶部84には、ゲームプログラム301、操作データ302、サーバ送信用データ305、更新用データ306、対戦相手データ307、現在モード308、待機ブロックデータ309、現在作戦データ310、現在バッジ数データ311、および、画像データ312等が記憶されている。
【0088】
ゲームプログラム301は、本実施形態にかかるゲーム処理を実行するためのプログラムである。
【0089】
操作データ302は、上記左コントローラ3および右コントローラ4から得られるデータであり、ユーザの操作内容を示すデータである。当該操作データ302には、各コントローラが有する各種ボタンの押下状態を示すデジタルボタンデータ303、アナログスティックに対する操作内容を示すアナログスティックデータ304等が含まれている。
【0090】
サーバ送信用データ305は、ゲームシステム1からサーバ101に送信するためのデータである。
図21に、当該サーバ送信用データ305の構成の一例を示す。
図21において、サーバ送信用データ305には、ユーザID321、プレイフィールド情報322、攻撃関連情報323、標的情報324、ゲームオーバー情報325、観戦情報326、バッジ情報327等が含まれている。
【0091】
ユーザID321は、本ゲームに参加している99人のユーザのそれぞれを一意に識別するための情報である。
【0092】
プレイフィールド情報322は、上記プレイフィールド1511の状態を示すためのデータである。具体的には、縦20×横10マスのそれぞれについてのブロックの有無を示す情報が含まれている。また、ブロックが有る場合は、そのブロックの内容(例えば色・柄、形状等)を示す情報も含まれる。
【0093】
攻撃関連情報323は、「標的」に対するお邪魔ブロックの送り込み(攻撃)が発生したか否かを示す情報である。また、お邪魔ブロックの送り込みが発生している場合は、送り込むお邪魔ブロックの行数(攻撃力)を示す情報も含まれる。換言すれば、当該攻撃関連情報323は、後述の標的情報324と合わせて、サーバ101を介して「標的」のゲームシステム1に対して、お邪魔ブロックを出現させる指示を行うためのデータであるといえる。
【0094】
標的情報324は、上記「標的」を特定するための情報である。
【0095】
ゲームオーバー情報325は、そのユーザがゲームオーバーになっているか否かを示す情報である。また、ゲームオーバーになった場合は、いずれかの対戦相手からお邪魔ブロックが原因でゲームオーバーとなったのか否かを示す情報と、当該原因となった対戦相手を特定するための情報が当該ゲームオーバー情報325に含まれる。
【0096】
観戦情報326は、そのユーザが上記観戦モードであるか否かを示す情報である。観戦モードである場合は「観戦中」を示す情報が観戦情報326に設定される。
【0097】
バッジ情報327は、そのユーザが現在所持しているバッジ数を示すデータである。
【0098】
図20に戻り、更新用データ306は、サーバ101から受信したデータであって、後述の対戦相手データ307を更新するためのデータである。
図22に、当該更新用データ306のデータ構成の一例を示す。更新用データ306は、基本的には、上記サーバ送信用データ305と同様の内容であるデータを1レコード(1行)としたテーブル形式のデータである。つまり、自分以外の他の98人の対戦相手から送信されたサーバ送信用データ305をサーバ101経由で受信したものといえる。具体的には、
図21で示した各データを同趣旨のデータである、ユーザID341、プレイフィールド情報342、攻撃関連情報343、標的情報344、ゲームオーバー情報345、観戦情報346、バッジ情報347等が1レコードとして構成されている、テーブル形式のデータである。各データの説明については
図21で説明したものと同様のため、割愛する。
【0099】
ここで、本実施形態の対戦ゲームでは、最大で99人のユーザが参加できるが、必ずしも99人が揃わなくてもよい。例えば、参加者が60人しかいなかった場合は、サーバ101のプロセッサが残り39人分のユーザとして振る舞う処理が実行される。このような場合、サーバ101において、プロセッサ81が担当する39人分のユーザ(以下、AIユーザと呼ぶ)についてもそれぞれ上記サーバ送信用データ305と同様の内容のデータがAIユーザの行動結果に基づいて生成される。そして、これらを含むデータが各ゲームシステム1に送信され、各ゲームシステム1において上記更新用データ306として格納される。
【0100】
また、更新用データ306には、例えば対戦相手同士での攻撃の応酬を示すデータが含まれていてもよい。すなわち、どの対戦相手がどの対戦相手を攻撃しているかを示すデータである。そして、このようなデータを用いて、第2領域152において、対戦相手同士の攻撃の様子を示す演出を表示するようにしてもよい。
【0101】
なお、更新用データ306の送受信に関して、他の実施形態では、上記のようなテーブル形式のデータとして纏めて送受信するのではなく、ユーザ毎のデータを1件(
図22の1レコード)単位で送受信するようにしてもよい。各ゲームシステム1とサーバ間の通信速度の差や通信ラグ等の発生を踏まえて、例えば、各ユーザからのサーバ送信用データ305がサーバ101に届き次第、個別に他のユーザのゲームシステム1にこれを送信するような構成としてもよい。
【0102】
図20に戻り、次に、対戦相手データ307は、自分以外の98人の対戦相手それぞれにかかるゲーム処理のゲーム状況を示すためのデータの一例であり、上記更新用データ306に基づいて適宜更新されるデータである。
図23に、対戦相手データ307の構成の一例を示す。対戦相手データ307は、上記第2領域152における98個の対戦相手画像1521のうちの一つを特定するための画像枠番号360を含む。そして、この画像枠番号360に、上記更新用データ306と同様の内容である、ユーザID361、プレイフィールド情報362、攻撃関連情報363、標的情報364、ゲームオーバー情報365、観戦情報366、およびバッジ情報367を関連づけて記憶した、テーブル形式のデータである。すなわち、対戦相手それぞれから送られた上記サーバ送信用データ305を上記第2領域152における98個の対戦相手画像1521のいずれかに割り当てたデータであるともいえる。
【0103】
図20に戻り、次に、現在モード308は、そのユーザが観戦モードであるか否か、あるいは、観戦モードへの遷移を問い合わせ中の状態(問い合わせ画面が表示されている状態)であるか否かを示すデータである。本例では、観戦モードへの遷移を問い合わせ中の
状態であれば「問い合わせ中」を示すデータが設定され、観戦モードに入っている場合は「観戦中」を示すデータが設定されるものとする。
【0104】
待機ブロックデータ309は、上記待機ブロック領域1512に表示される待機ブロック画像171に関するデータである。
図24に、待機ブロックデータ309のデータ構成の一例を示す。待機ブロックデータ309には、待機番号331と、対戦相手ID332と、攻撃力333と、経過時間334とが含まれる。待機番号331は、各待機ブロック画像171(すなわち待機ブロック)を識別するための番号である。対戦相手ID332は、当該待機ブロックを送り込んだ対戦相手のユーザIDを示す情報である。攻撃力333は、出現するお邪魔ブロック173の行数を示す情報である。経過時間334とは、当該待機ブロックが送り込まれてから経過した時間を示す。
【0105】
図20に戻り、次に、現在作戦データ310は、現在選択されている上記作戦を示すデータである。現在バッジ数データ311は、そのユーザが現在所持している上記バッジ数を示すデータである。また、画像データ312は、各種ブロックの画像や標的画像等の、本ゲーム処理で表示される各種画像のデータである。
【0106】
[サーバに記憶されるデータ]
次に、サーバ101で用いられるデータに関して説明する。
図25は、サーバ101の記憶部112に記憶される各種データの一例を示すメモリマップである。サーバ101の記憶部112には、サーバ処理プログラム321、参加ユーザデータ382、受信データ383、送信データ384等が記憶されている。
【0107】
サーバ処理プログラム381は、本実施形態にかかるゲーム処理においてサーバ101が担当する機能を処理させるためのプログラムである。主に、各ゲームシステム1から送信されるサーバ送信用データ305の受信処理、上記AIユーザの処理が必要な場合は、AIユーザとしてゲームを進行する処理、各ゲームシステム1に送信するデータを生成して送信する処理、等が当該プログラムによって実行される。
【0108】
参加ユーザデータ382は、本実施形態にかかる最大99人の対戦ゲームに参加したユーザに関するデータである。そのデータ構成としては、ゲームへの参加者99人分の上記サーバ送信用データ305の内容で構成されるテーブル形式のデータとなる。そのため、当該データの構成の詳細な説明は割愛する。
【0109】
受信データ383は、各ゲームシステム1から送信されてきたサーバ送信用データ305を一時的に記憶したデータである。このデータに基づいて上記参加ユーザデータ382が更新される。
【0110】
送信データ384は、各ゲームシステム1に、対戦相手の状況を送信するためのデータである。本実施形態では、そのデータ構成としては、上記参加ユーザデータ382の内容から、送信先のゲームシステム1にかかるユーザのデータを抜いた内容であるものとする。
【0111】
[全体的な処理の流れ]
次に、本実施形態にかかるゲーム処理の詳細を説明する。まず、
図26を用いて、サーバ101および各ゲームシステム1との協働による全体的な処理の流れを説明する。
図26においては、図の左側にゲームシステム側処理、右側にサーバ側処理を示している。まず、対戦ゲームの開始が所定のユーザによって指示されることで、各ゲームシステム1およびサーバ101との間で準備処理P1が実行される。この処理では、締め切り時間を設定したうえで、最大99人のユーザの参加受付が行われる。その後、締め切り時間が経過
すれば、参加者が99人に足りない場合はその分のAIユーザの設定が適宜行われ、当該AIユーザを含む対戦相手の情報が各ゲームシステムに送信され、上記のようなパズルゲームを実行する処理P2が開始される。その後、ゲームオーバーになったユーザが出てきたときは、必要に応じて、上記のようにゲームオーバーに追い込んだことユーザに対して、獲得したバッジ数を示す情報(以下、獲得バッジ情報)を所定のユーザに送信する処理が実行される。更に、ゲームオーバーとなったユーザが98人になれば、サーバ101は各ゲームシステムに、最終的な順位が確定した旨と、各ユーザの最終順位とユーザ名等を示す情報(以下、終了処理用データと呼ぶ)を送信する。その後、各ゲームシステムで最終順位の表示等の処理が実行され、当該ゲームを終了する処理P3(通信セッションの切断等)が行われることで、本実施形態にかかるゲームは終了となる。
【0112】
[ゲームシステム側で実行される処理の詳細]
次に、各ゲームシステム1で実行されるゲーム処理の詳細を説明する。
図27~
図29は、本ゲーム処理の詳細を示すフローチャートである。また、この処理は、上記締め切り時間が終了した後に実行される処理である。また、当該図面で示すフローチャートは、処理過程の単なる一例にすぎない。したがって、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判断ステップで利用される閾値も、単なる一例に過ぎず、必要に応じて他の値を採用してもよい。
【0113】
まず、
図27のステップS1で、ゲームを開始するための各種の準備処理が実行される。具体的には、プロセッサ81は、各対戦相手の情報が含まれている更新用データ306をサーバから受信する。そして、これに基づき、各対戦相手を上記第2領域152の対戦相手画像1521のいずれかに割り当てることで、対戦相手データ307を生成する。また、図示は省略するが、落下するブロックの順番を示す落下順番データもこの時点でサーバ101から受信し、記憶部84に格納しておく。この後に実行されるパズルゲームでは、当該落下順番データに基づいた順番で上記ブロックが出現し、また、ネクストブロック領域1513の表示内容も適宜更新される。また、プロセッサ81は、上記作戦の初期値として「ランダム」を示す情報を現在作戦データ310に設定する。
【0114】
その後、上記対戦相手データ307に基づいて第2領域152に表示する画像が生成され、また、上記落下順番データ等に基づいて第1領域151に表示する画像も生成される。そして、これら画像を含むゲーム画像がディスプレイ12に出力される。その後、所定のカウントダウン演出が行われて、パズルゲームが開始される。なお、以下のステップS2~S29の処理ループは、例えば1フレーム毎に繰り返し実行されるものとする。
【0115】
次に、ステップS2で、プロセッサ81は、更新用データ306をサーバから受信する。また、その他、上記獲得バッジ数データ、上記終了処理用データがあれば、当該データの受信も行われる。
【0116】
続くステップS3で、プロセッサ81は、各種データを更新する処理を実行する。まず、プロセッサ81は、更新用データ306に基づいて対戦相手データ307を更新する。これにより、対戦相手のゲーム進行状況が更新されることになる。なお、当該対戦相手データの更新間隔については、1フレーム毎ではなく、例えば1秒間隔等の所定間隔での更新としてもよい。本ゲームは、基本的にはパズルゲーム自体は各ゲームシステム1で独立して進行可能であるため、それほど厳密には他のゲームシステム1との間で同期を取らなくてもよいからである(本ゲームでは、通信について多少のタイムラグがあっても、その影響は小さいと考えられる)。また、その他、更新後の対戦相手データ307の攻撃関連情報363に基づき、待機ブロックデータ309の内容も適宜更新される。つまり、対戦相手から受けた攻撃に関して反映する処理も実行される。
【0117】
更に、ステップS2で獲得バッジ数データを受信していれば、これに基づいて現在バッジ数データ311およびバッジ情報327に所定の値が加算され、これらのデータが更新される。上記のように、「標的」を自身の送り込んだお邪魔ブロックでゲームオーバーに追い込んだ場合に、獲得バッジ数データがサーバ101から送信され、所定数のバッジを獲得できる。
【0118】
次に、ステップS4で、プロセッサ81は、今回の対戦ゲームの終了条件が満たされたか否かを判定する。具体的には、上記ステップS2において、サーバ101から上記終了処理用データを受信しているか否かが判定される。その結果、終了条件が満たされていた場合は(ステップS4でYES)、ステップS6で、プロセッサ81は、今回の対戦ゲームを終了するための処理を実行する。具体的には、サーバ101から受信した上記終了処理用データに基づいて、各ユーザの最終順位を表示する等の処理を実行する。その後、サーバ101との通信を切断するための処理を実行して本ゲーム処理は終了する。
【0119】
一方、上記ステップS4の判定の結果、終了条件が満たされていない場合は(ステップS4でNO)、ステップS5で、プロセッサ81は、待機ブロックデータ309を参照し、その時点で存在している待機ブロックについての経過時間334を更新する。例えば、経過時間334をカウントアップする処理が実行される。
【0120】
次に、ステップS7で、プロセッサ81は、操作データ302を取得する。次に、ステップS8で、プロセッサ81は、現在モード308が「観戦中」であるか否かを判定する。つまり、ユーザが(既にゲームオーバーとなっていて)観戦モードに入っているか否かを判定する。当該判定の結果、「観戦中」の場合は(ステップS8でYES)、後述するステップS26に処理が進められる。
【0121】
一方、「観戦中」ではない場合は(ステップS8でNO)、次に、ステップS9で、プロセッサ81は、現在モード308が「問いあわせ中」であるか否かを判定する。「問いあわせ中」の場合は、
図28のステップS12で、プロセッサ81は、操作データ302で示される操作内容が観戦モードへの遷移指示であるか否かを判定する。その結果、遷移指示が行われていた場合は(ステップS12でYES)、ステップS13で、プロセッサ81は、当該ユーザがゲームオーバーになったことを示す情報を含むようにゲームオーバー情報325を更新する。更に、ステップS14で、プロセッサ81は、現在モード308および、上記サーバ送信用データ305の観戦情報326に「観戦中」を示す情報を設定する。その後、後述のステップS26に処理が進められる。
【0122】
一方、ステップS12の判定の結果、遷移指示が行われていない場合は(ステップS12でNO)、ステップS15で、プロセッサ81は、操作データ302で示される操作内容がゲームを終了する旨の指示であるか否かを判定する。つまり、ゲームオーバーになった後、観戦せずにゲームを終了することがユーザによって選択されたか否かが判定される。終了指示である場合は、ステップS16で、プロセッサ81は、当該ユーザがゲームオーバーになったことを示す情報を含むようにゲームオーバー情報325を更新する。続くステップS17で、プロセッサ81は、サーバ送信用データ305をサーバ101に送信する処理を実行する。その後、ステップS18で、プロセッサ81は、当該ゲームを終了するための処理を実行する。なお、上記ステップS6の処理とは異なり、ここでは、最終順位の表示等は行われずに、ゲーム処理が終了される(いわば、ゲームから途中退出するような処理となる)。また、上記ステップS17における送信処理により、サーバ101(および他の対戦相手)には、当該ユーザがゲームオーバーになったこと、および、その後の観戦はしないことが通知されることになる。
【0123】
図27に戻り、上記ステップS9の判定の結果、「問いあわせ中」ではない場合は(ス
テップS9でNO)、ステップS10で、プロセッサ81は、操作データで示される操作内容が上述したような作戦の変更操作であるか否か(本例では、右コントローラ4が備えるアナログスティックの操作)が判定される。当該判定の結果、作戦の変更操作が行われていた場合は(ステップS10でYES)、操作データ302で示される操作内容に基づいて、現在作戦データ310の内容が更新される。その後、後述のステップS26に処理が進められる。
【0124】
一方、ステップS10の判定の結果、作戦変更操作が行われていない場合は(ステップS10でNO)、次に、
図29のステップS19で、プロセッサ81は、現在作戦データ310を参照して、現在選択されている作戦に基づいて、上記「標的」を選択する処理を実行する。具体的には、以下のような処理がプロセッサ81によって実行される。まず、現在の作戦が「とどめ狙い」の場合は、プロセッサ81は、上記対戦相手データ307を参照し、各対戦相手のプレイフィールド情報362に基づいて、上述したような「ピンチ状態」になっている対戦相手を抽出する。抽出の結果、「ピンチ状態」の対戦相手が1人だけであれば、その対戦相手を「標的」として設定するため、標的情報324に当該対戦相手を示すユーザID361を設定する。また、「ピンチ状態」の対戦相手が複数いた場合は、そのうちの1人を「標的」として決定して(決定の仕方はどのような手法でもよい)、標的情報324に設定する。また、現在の作戦が「ランダム」であれば、プロセッサ81は、対戦相手からランダムで1人を選択して、当該対戦相手を示すユーザID361を標的情報324に設定する。また、現在の作戦が「バッジ狙い」の場合は、プロセッサ81は、上記対戦相手データ307を参照し、各対戦相手のバッジ情報367に基づいて所定の対戦相手を選択し、当該対戦相手を示すユーザID361を標的情報324に設定する。また、現在の作戦が「カウンター」の場合は、プロセッサ81は、上記対戦相手データ307を参照し、標的情報364に基づいて自分を「標的」として設定している対戦相手を特定する。そして、特定した対戦相手のユーザID361(複数いた場合はその全員分のユーザID361)をサーバ送信用データ305の標的情報324に設定する。
【0125】
次に、ステップS20で、プロセッサ81は、操作データに基づいて、あるいは、時間の経過に基づいて、上記ブロックをプレイフィールド1511内で移動させる。操作データ302で示される操作内容がブロックの左右、下方向の移動、または回転させる操作であれば、当該操作内容に応じてブロックを移動あるいは回転させる。また、ブロックに対するユーザからの操作がなかった場合でも、所定の時間が経過する毎に、ブロックを1マス分下方向に移動させる処理も行われる。
【0126】
次に、ステップS21で、プロセッサ81は、ブロックの配置位置が確定されたか否かを判定する。まだ確定されていない場合は(ステップS21でNO)、後述のステップS23に処理が進められる。確定した場合は(ステップS21でYES)、ステップS22で、プロセッサ81は、ブロック消去関連処理を実行する。
【0127】
図30は、当該ブロック消去関連処理の詳細を示すフローチャートである。まず、ステップS41で、プロセッサ81は、上記ブロックの配置が確定した結果、ブロックの消去条件が満たされたか否かを判定する。本実施形態では、プレイフィールド1511の横1行分が埋まったブロックがあるか否かが判定される。当該判定の結果、消去条件が満たされていない場合は(ステップS41でNO)、後述のステップS49の処理に進む。一方、消去条件が満たされている場合は(ステップS41でYES)、次に、ステップS42で、プロセッサ81は、消去するブロックにかかる行数を算出する。つまり、何行分消去できるのかが算出される。
【0128】
次に、ステップS43で、消去する行数に基づいて、上記基礎攻撃力を算出する。本例では、消去する行数と基礎攻撃力とが同じ値であるものとする。例えば消去行数が1であ
れば基礎攻撃力は1、消去行数が3であれば基礎攻撃力は3である。
【0129】
次に、ステップS44で、プロセッサ81は、待機ブロックデータ309を参照して、現在、待機ブロックが存在しているか否かを判定する。存在していない場合は(ステップS44でNO)、後述のステップS47に処理が進められる。存在している場合は(ステップS44でYES)、続くステップS45で、消去する行数と待機ブロックとを相殺する処理が実行される。例えば、待機ブロック画像171が3個存在している状態で2行消去できる場合は、待機ブロックデータ309の攻撃力333から2を減算する。これに応じて、画面に表示されている待機ブロック画像171を減らすための処理も実行される。また、当該減算の結果、攻撃力が0以下になった場合は、当該攻撃力が0となった待機ブロックにかかるレコードを待機ブロックデータ309から削除する処理も実行される。また、例えば、待機ブロックデータ309において、待機番号331が”1”の待機ブロックと待機番号331が”2”の待機ブロックとがある場合を想定する。そして、待機番号331が”1”の待機ブロックの攻撃力が”1”であり、待機番号331が”2”の待機ブロックの攻撃力が”3”であったとする。この場合に、2行消去した場合は、待機番号331が”1”の待機ブロックは完全に相殺され、待機番号332が”2”の待機ブロックについては1行分だけ相殺される(攻撃力333が2に減算される)ことになる。つまり、待機番号331が小さい順に相殺されていく。
【0130】
次に、ステップS46で、プロセッサ81は、上記相殺した内容に応じて、基礎攻撃力を減算する。例えば1行分の相殺が行われていた場合は、基礎攻撃力から”1”が減算される。
【0131】
次に、ステップS47で、プロセッサ81は、上記基礎攻撃力を、バッジ情報327で示される自身のバッジの所持数に基づき補正する。更に、現在選択されている作戦が「カウンター」である場合は、自分を「標的」にしている対戦相手の数に基づいて補正する。例えば、バッジの所持数が1である場合は、基礎攻撃力に1が加算される。更に、「カウンター」作戦の場合であって、3人の対戦相手から「標的」にされている場合は(上記対戦相手データ307に基づいて判別可能である)、バッジによる加算とは別に、基礎攻撃力に更に1が加算される。一例ではあるが、「基礎攻撃力+バッジ数による補正攻撃力+「カウンター」作戦による補正攻撃力」が「標的」に対する最終的な攻撃力として算出されることになる。そして、このように算出された攻撃力を、「標的」への攻撃が発生したことを示す情報と共に、サーバ送信用データ305の攻撃関連情報323に設定する。
【0132】
次に、ステップS48で、プロセッサ81は、上記ブロックの消去に伴い、プレイフィールド1511の内容を更新する処理を実行する。つまり、上記消去後のブロックの配置を更新する処理が実行される。
【0133】
次に、ステップS49で、プロセッサ81は、お邪魔ブロック処理を実行する。
図31は、当該お邪魔ブロック処理の詳細を示すフローチャートである。
図31において、まず、ステップS61で、プロセッサ81は、待機ブロックデータ309を参照して、経過時間334が予め設定されている所定の待機時間を越えた待機ブロックがあるか否かを判定する。当該判定の結果、このような待機ブロックがない場合は(ステップS61でNO)、当該お邪魔ブロック処理は終了する。一方、このような待機ブロックがある場合は(ステップS61でYES)、次に、ステップS62で、プロセッサ81は、上記お邪魔ブロック173を生成する。具体的には、待機ブロックデータ309の攻撃力333に基づいて、出現させるお邪魔ブロック173の行数を決定する。そして、各行にかかるお邪魔ブロック173の内容を決定する。本例では、上記
図10を用いて説明したように、横1行分のうちいずれか1マスだけランダムで空白にした9個分のブロックがお邪魔ブロック173として生成される。
【0134】
次に、ステップS63で、プロセッサ81は、上記生成したお邪魔ブロック173をプレイフィールド1511に配置し、配置後のプレイフィールド1511の内容を更新する処理を実行する。本例では、下からせり上がるようにしてお邪魔ブロックが配置される。また、出現させたお邪魔ブロック173に対応する待機ブロックについては、待機ブロックデータ309から削除する処理も実行される、また、これに伴い、対応する待機ブロック画像171を待機ブロック領域1512から消去する処理も実行される。その後、お邪魔ブロック処理は終了する。
【0135】
図30に戻り、次に、ステップS50で、プロセッサ81は、上記落下順番データに基づき、次に落下してくるブロックを表示するための処理を実行する。また、ネクストブロック領域1513の表示内容を更新する処理も実行する。その後、ブロック消去関連処理は終了する。
【0136】
図29に戻り、次に、ステップS23で、プロセッサ81は、プレイフィールド1511の状況が、ゲームオーバーとなる条件を満たしたか否かを判定する。本例では、プレイフィールドの最上段までブロックが積み上がった場合にゲームオーバーの条件を満たしたと判定される。当該判定の結果、ゲームオーバーではない場合は(ステップS23でNO)、ステップS24で、プロセッサ81は、プレイフィールド1511の状況が、上記「ピンチ状態」であるか否かを判定する。その結果、「ピンチ状態」でなければ(ステップS24でNO)、ステップS26に処理が進められる。一方、「ピンチ状態」であれば(ステップS24でYES)、ステップS25で、プロセッサ81は、「ピンチ状態」であることを示すようにプレイフィールド1511の表示態様を変化させる。
【0137】
次に、ステップS26で、プロセッサ81は、上記処理の内容を反映したゲーム画像を生成し、ディスプレイ12に出力する。具体的には、上記対戦相手データ307のプレイフィールド情報362に基づいて、上記第2領域152に表示する画像、すなわち、合計98個の対戦相手画像1521を生成する。また、プロセッサ81は、標的情報324に基づき、標的画像161を自分が標的としている対戦相手画像1521に重畳する。また、プロセッサ81は、対戦相手データ307の標的情報364に基づき、上記「CAUTION」パネル162をプレイフィールド1511の下部に配置し、更に、自分を狙っている対戦相手にかかる対戦相手画像1521と、上記「CAUTION」パネル162とを結ぶ上記直線163を生成して配置する。また、プロセッサ81は、待機ブロックデータ309、現在作戦データ310、現在バッジ数データ311に基づき、待機ブロック領域1512、バッジ表示領域1514、作戦操作パネル1515の表示内容も決定する。また、プロセッサ81は、ゲームオーバー情報365を参照して各対戦相手がゲームオーバーとなっているか否かを判定する。対戦相手がゲームオーバーとなっている場合は、更に観戦情報366に基づいて、その対戦相手が観戦モードであるか否かを判定する。そして、当該判定の結果に基づいて、ゲームオーバーであること、および、観戦しているか否かを示す画像(上記
図17、
図18参照)を対戦相手画像1521として生成する。これにより、98人の対戦相手のゲームの状況をユーザに提示することができる。更に、プロセッサ81は、上記第1領域151に表示する画像として、上記のようなプレイフィールド1511に関する各種処理が反映された画像も生成する。但し、ユーザがゲームオーバーとなり、観戦モードにはいっている場合は、それ以上プレイフィールド内容の更新は行われないため、ゲームオーバー時のプレイフィールド1511の状態を示す画像が生成される。そして、これらを組み合わせて、出力すべきゲーム画像が生成され、ディスプレイ12に出力される。
【0138】
続くステップS27で、プロセッサ81は、サーバ送信用データ305のプレイフィールド情報322の内容を、上記の処理が反映された後のプレイフィールド1511の状況
を示すように更新する処理を実行する。なお、ユーザがゲームオーバーとなった後(現在モード308が「問いあわせ中」または「観戦中」の場合)は、当該プレイフィールド情報322の更新は行われない。
【0139】
次に、ステップS28で、プロセッサ81は、サーバ送信用データ305をサーバ101に送信する処理を実行する。その後、上記ステップS2に戻り、処理が繰り返される。
【0140】
一方、上記ステップS23の判定の結果、ゲームオーバーである場合は(ステップS23でYES)、ステップS29で、ゲームオーバー処理が実行される。
図32は、当該ゲームオーバー処理の詳細を示すフローチャートである。まず、ステップS81で、プロセッサ81は、今回のゲームオーバーが、お邪魔ブロック173の出現によるゲームオーバーであるか否かを判定する。その結果、お邪魔ブロック173の出現によるものではない場合は(ステップS81でNO)、ステップS83に処理が進められる。一方、お邪魔ブロック173の出現によるものであった場合は(ステップS81でYES)、ステップS82で、プロセッサ81は、ゲームオーバー情報325の更新を行う。具体的には、プロセッサ81は、当該お邪魔ブロック173を送り込んだ対戦相手にバッジを獲得させるための情報をゲームオーバー情報325に設定する処理を実行する。すなわち、当該お邪魔ブロックを送り込んだ対戦相手のユーザID、および、その時点でユーザが所持しているバッジ数を示す情報を含むようにゲームオーバー情報325が設定される。これにより、ここで示される対戦相手に対して当該ユーザがその時点で所持していたバッジを付与することができる。
【0141】
次に、ステップS83で、プロセッサ81は、現在モード308に「問いあわせ中」を設定する。次に、ステップS84で、プロセッサ81は、観戦するか否かをユーザに問いあわせる問い合わせ画面を生成し、ディスプレイ12に出力する。以上で、ゲームオーバー処理は終了する。ゲームオーバー処理が終われば、上記ステップS2に戻り、処理が繰り返される。
【0142】
以上で、各ゲームシステム1で実行されるゲーム処理の詳細説明を終了する。
【0143】
[サーバ側の処理の詳細]
次に、サーバ101で実行される処理の詳細について説明する。
図33は、サーバのプロセッサ111によって実行されるサーバ処理の詳細を示すフローチャートである。まず、ステップS101で、プロセッサ111は、準備処理を実行する。具体的には、ゲームに参加する各ゲームシステム1から送信されるデータに基づいて上記参加ユーザデータ382を生成する。この際、上記参加人数が99人に足りていない場合は、足りない分のユーザをAIユーザとしてプロセッサ111が担当する。そのため、このAIユーザにかかるデータも参加ユーザデータ382に含めるようにして生成する。その後、対戦ゲーム開始の準備が整えば、対戦ゲームの開始を示す情報を各ゲームシステム1に送信する。
【0144】
次に、ステップS102で、プロセッサ111は、参加ユーザデータ382を参照して、ゲーム終了条件が満たされたか否かを判定する。例えば、ゲームオーバーとなったユーザが98人に達したか否かを判定する。当該判定の結果、終了条件が満たされていない場合は(ステップS102でNO)、ステップS103で、プロセッサ111は、受信処理を実行する、すなわち、各ゲームシステム1から送信されてくるサーバ送信用データ305を受信する。
【0145】
次に、ステップS104で、プロセッサ111は、上記AIユーザにかかるパズルゲーム処理を実行する。なお、AIユーザが不要な場合は、当該処理は行われない。
【0146】
次に、ステップS105で、プロセッサ111は、上記受信したデータ、および、上記AIユーザのパズルゲーム処理の結果に基づいて、参加ユーザデータ382を更新する。
【0147】
次に、ステップS106で、プロセッサ111は、ゲームオーバー時の上記バッジの獲得に関する処理を実行する。すなわち、参加ユーザデータに含まれるゲームオーバー情報に基づいて、所定のユーザにバッジを獲得させるための処理を実行する。例えば、ユーザAがユーザBから送り込まれたお邪魔ブロックによりゲームオーバーとなった場合は、ユーザAから送信されるゲームオーバー情報325にこのことを示す情報が含まれている。これに基づき、プロセッサ111は、ユーザBに対してバッジを1つ獲得させることを決定する。更に、当該ユーザAのバッジ情報327を参照し、ユーザAが1以上のバッジを所持していた場合は、そのバッジ数を更に加算してユーザBに獲得させることを決定する。そして、ユーザBに獲得させるバッジ数を示す情報を、ユーザBを宛先とする上記獲得バッジ数データとして生成する。
【0148】
次に、ステップS107で、プロセッサ111は、各ゲームシステム1に送信するための送信データを生成する。具体的には、送信先のゲームシステム1にかかるユーザ以外のユーザにかかるデータを送信データとして生成する。例えばユーザAに対する送信データとしては、ユーザA以外の98人分のユーザのデータを含む送信データが生成される。また、上記獲得バッジ数データを生成していた場合は、該当するユーザに対する送信データに当該データを含める。そして、ゲームに参加している各ゲームシステム1に送信データを送信する。なお、このとき、ゲームオーバーになったユーザであって、観戦しないことを選んだユーザにかかるゲームシステム1に対しては、送信しないようにしてもよい。当該処理の後、上記ステップS102に戻って処理が繰り返される。
【0149】
一方、上記ステップS102の判定の結果、ゲーム終了条件が満たされていた場合は(ステップS102でYES)、ステップS108で、プロセッサ111は、最終順位等の情報を含めた上記終了処理用データを生成し、各ゲームシステム1に対して送信する。なお、この場合も、ゲームオーバーになったユーザであって、観戦しないことを選んだユーザにかかるゲームシステム1に対しては、送信しないようにしてもよい。
【0150】
以上で、サーバ側の処理の説明を終了する。
【0151】
このように、本実施形態では、98人という多数の対戦相手が存在する対戦ゲームにおける攻撃対象相手の選択について、上記のような「作戦」を選択させることにより、ユーザの意思を反映させつつも容易な選択操作が可能となっている。これにより多数の相手と対戦するようなゲームにおいて、攻撃対象とする等で相手を指定する必要性があるゲームにおける選択のやりやすさをより向上させることができる。
【0152】
また、上記のような多数の対戦相手それぞれに対応づけられた画像も表示し、上記標的画像161や「CAUTION」パネル162および直線163を表示している。これにより、自分が誰を選択しているか、あるいは、自分が誰から選択されているかをよりわかりやすく提示できる。
【0153】
[変形例]
【0154】
なお、上記実施形態では、各ユーザの順位表示については、ゲームオーバーとなって順位が確定したときに表示する例を示した。この他、他の実施形態では、リアルタイムに順位を表示するようにしてもよい。例えば、上記のような対戦ゲームにおいて上述した「バッジ」の所持数で順位を決めるような場合は、各ユーザのバッジの所持数に応じて、例えば対戦相手画像1521に重畳してその時点での順位を表示してもよい。そして、バッジ
所持数の変化に応じてリアルタイムに順位表示を変更するようにしてもよい。
【0155】
また、上記実施形態では、「標的」としている対戦相手画像1521の重畳するようにして標的画像161を表示していた。他の実施形態では、標的画像161を表示する代わりに、当該対戦相手画像1521自体の表示態様を変化させるようにしてもよい。例えば、その大きさを少し拡大して表示してもよいし、当該対戦相手画像1521に所定のアニメーション演出を行うようにしてもよい。
【0156】
また、対戦相手のゲーム状況を変化させる手法の一例として、上記の説明では「お邪魔ブロック」に対戦相手に送り込むことで対戦相手のパズルゲームの進行を妨害する例を用いて説明していた。対戦相手のゲーム状況を変化させる手法はこれに限るものではない。他の実施形態では、例えば、対戦相手の体力・HP等の耐久力を減少させたり、対戦相手の持ち時間を減少させたり、対戦相手が行っているゲーム操作を一時的に受け付けないようにする等、対戦相手のゲーム進行の妨害となるような内容であれば、上記「お邪魔ブロック」以外の手法を用いてもよい。
【0157】
また、第2領域152における表示に関して、上記実施形態では、ゲームオーバーとなった対戦相手の表示として、上記
図17で示したような「KO」の画像等を表示していた。すなわち、ゲームオーバーになった場合にその表示を変更していた。この点に関して、他の実施形態では、第2領域152を用いて、いわゆるビンゴゲームの要素を利用した処理を行ってもよい。つまり、7×7の配列で対戦相手画像1521が並べられている中で、ユーザの攻撃によってゲームオーバーになったユーザにかかる対戦相手画像1521が、縦・横・斜めのいずれか一列に並んだことに応じて(ビンゴの成立)、例えば上記攻撃力の向上等、何らかの効果を付与するようにしてもよい。これにより、ゲームの興趣性を更に高めることが可能となる。
【0158】
また、他の実施形態では、
図5で示したようなゲーム画像構成を利用して、49vs49のチームバトルとして上記のようなゲームを実行してもよい。例えば、ユーザは2つのチームのいずれかに属し、上記
図5における第2領域152Lには、ユーザ自身を含む49人の味方チームのプレイフィールド1511の状況を示す49個の対戦相手画像1521が表示される。第1領域151には、上記実施形態同様にユーザが操作するプレイフィールド1511等が表示される。そして、第2領域152Rには、残り49人のユーザで構成される敵チームにかかる49個の対戦相手画像1521が表示される。この場合は、「標的」として設定できる相手を敵チームにかかる対戦相手に限定すればよい。そのため、上記標的画像161や直線163については、第2領域152Rの対戦相手画像1521のいずれかを対象として表示されることになる。これにより、上記実施形態と同様のゲーム画像構成や表示要素を利用して、チーム戦という上記実施形態とは別のゲーム性を有する対戦ゲームを実現することができる。
【0159】
また、他の実施形態では、上記サーバ101を介さずに、例えば近距離無線通信等を用いてゲームシステム1同士で接続(ピア・ツー・ピア)して、上述したような対戦ゲーム処理を行うような構成としてもよい。
【0160】
また、例えば、ユーザは1人で、残り98人の対戦相手全てを上記AIユーザとして、単一のゲームシステム1だけで上記のゲーム処理を実行するような構成でもよい。この場合、上記ゲーム状況を示すデータのやりとりについては当該ゲームシステム1内で完結するような構成となる。例えばプロセッサ81が担当する98人分のAIユーザにかかる上記サーバ送信用データ305を、サーバ101に送信する代わりに記憶部84に更新用データ306として格納するような構成とすればよい。
【0161】
また、上記実施形態では、上から落下してくるパズルオブジェクトを積み上げ、横1行並べて消去するようなアクションパズルゲーム処理を例にしたが、このようなパズルゲームに限らず、様々なアクションパズルゲーム処理についても上記のような処理は適用可能である。例えば、上記パズルオブジェクトが下方から上に向かって出現するようなパズルゲーム処理等にも適用できる。
【0162】
また、上記実施形態では、ゲーム処理の一例として、パズルゲームを例に挙げて説明したが、ゲーム処理はパズルゲーム処理に限るものではない。他の実施形態では、ユーザと複数の対戦相手とのそれぞれにかかるゲーム処理が独立して進行するゲームであれば、パズルゲーム以外のゲーム処理に上記のような処理を適用してもよい。
【0163】
また、第1領域151と第2領域152の配置位置関係に関して、上記の例ではゲーム画像の中央に第1領域151を配置し、その左右に2つの第2領域152を配置する例を示した。これに限らず、第2領域152の位置に関しては、例えば第1領域151の上下であってもよい。更には、第2領域152の位置は固定せず、例えば第1領域151の周囲を周回するように常に移動させるようにしてもよい。
【0164】
また、上記のゲーム処理は、上述したゲームシステム1に限らず、例えば携帯型ゲーム装置やスマートフォン等の情報処理装置でも実行可能である。ここで、表示画面を2つ備える携帯型ゲーム装置で上記の処理を実行する場合は、例えば第1の表示画面に上記第1の領域(ユーザのゲームプレイに関する画像)を表示し、第2の表示画面に上記第2領域(つまり、98人の対戦相手にかかる対戦相手画像1521)を表示するような構成としてもよい。
【0165】
また、他の実施形態においては、各ユーザのゲーム処理にかかる上記一連の処理について、複数の情報処理装置からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの一部の処理がサーバ側装置によって実行されてもよい。更には、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。例えば、主要なゲーム処理はサーバ側装置で実行し、端末側装置では主にサーバ側装置でのゲーム処理の結果生成されたゲーム画像を受信して表示させることでゲームを進行させるようにしてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。
【符号の説明】
【0166】
1 ゲームシステム
2 本体装置
3 左コントローラ
4 右コントローラ
12 ディスプレイ
81 プロセッサ
84 記憶部