特許7553509情報処理プログラム、情報処理装置、情報処理システム、および情報処理方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-09-09
(45)【発行日】2024-09-18
(54)【発明の名称】情報処理プログラム、情報処理装置、情報処理システム、および情報処理方法
(51)【国際特許分類】
A63F 13/422 20140101AFI20240910BHJP
A63F 13/58 20140101ALI20240910BHJP
A63F 13/55 20140101ALI20240910BHJP
A63F 13/49 20140101ALI20240910BHJP
A63F 13/53 20140101ALI20240910BHJP
【ＦＩ】
A63F13/422
A63F13/58
A63F13/55
A63F13/49
A63F13/53
【請求項の数】
13
(21)【出願番号】P 2022107689
(22)【出願日】2022-07-04
(65)【公開番号】P2023166049
(43)【公開日】2023-11-20
【審査請求日】2023-11-06
(73)【特許権者】
【識別番号】000233778
【氏名又は名称】任天堂株式会社
(74)【代理人】
【識別番号】110001276
【氏名又は名称】弁理士法人小笠原特許事務所
(74)【代理人】
【識別番号】100130269
【弁理士】
【氏名又は名称】石原 盛規
(72)【発明者】
【氏名】神門 有史
【審査官】岸 智史
(56)【参考文献】
【文献】特開２０２０－１８８９８５（ＪＰ，Ａ）
【文献】特開２０００－２３７４４７（ＪＰ，Ａ）
【文献】特開２００６－２３０５８７（ＪＰ，Ａ）
【文献】特開２０２０－０５４５０２（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ａ６３Ｆ ９／２４、１３／００－１３／９８
(57)【特許請求の範囲】
【請求項1】
情報処理装置のコンピュータにおいて実行される情報処理プログラムであって、前記コンピュータを、
各々のオブジェクトに関連付けられたオブジェクトタイプの中から第１オブジェクトタイプを利用オブジェクトタイプとして決定するタイプ決定手段と、
ユーザによる第１入力操作が行われたことを検出する検出手段と、
前記第１入力操作が１回行われる毎に前記利用オブジェクトタイプに関連付けられた前記オブジェクトを利用するイベントを発生させる処理を行うイベント発生手段と、
前記イベントが発生する毎に、当該利用オブジェクトタイプに対応付けられたカウンタを変化させるカウント変化処理を行うカウンタ変化手段と、
仮想空間を表す表示用画像を生成する画像生成手段として機能させ、
前記タイプ決定手段は、前記利用オブジェクトタイプに対応付けられた前記カウンタが基準範囲に含まれるようになった場合に、前記利用オブジェクトタイプを前記第１オブジェクトタイプから第２オブジェクトタイプに切り替え、
前記イベント発生手段は、前記ユーザによる前記第１入力操作が複数回繰り返し行われている場合に、前記カウンタが前記基準範囲に含まれるようになったときは、前記第２オブジェクトタイプに関連付けられた前記オブジェクトを利用する前記イベントを発生させる処理を一時的に停止した後に再開する、情報処理プログラム。
【請求項2】
前記イベント発生手段は、前記ユーザによる前記第１入力操作が複数回繰り返し行われている場合に、前記カウンタが前記基準範囲に含まれるようになったときであっても、一時停止条件を満たさない状態であるときは、前記第２オブジェクトタイプに関連付けられた前記オブジェクトを利用する前記イベントを発生させる処理を継続して行う、請求項１に記載の情報処理プログラム。
【請求項3】
前記一時停止条件は、前記イベントの対象である対象オブジェクトが第１カテゴリに含まれる場合に満たされ、第２カテゴリに含まれる場合は満たされない、請求項２に記載の情報処理プログラム。
【請求項4】
前記一時停止条件は、前記第２オブジェクトタイプが第１カテゴリに含まれる場合に満たされ、第２カテゴリに含まれる場合は満たされない、請求項２に記載の情報処理プログラム。
【請求項5】
前記イベント発生手段は、前記イベントの対象である対象オブジェクトが含まれるカテゴリと前記第２オブジェクトタイプが含まれるカテゴリとの組み合わせに基づいて、前記一時停止条件が満たされるか否かを判定する、請求項２に記載の情報処理プログラム。
【請求項6】
前記イベント発生手段は、前記ユーザによる前記第１入力操作が複数回繰り返し行われている場合に、前記ユーザの第２入力操作によって前記利用オブジェクトタイプが前記第１オブジェクトタイプから前記第２オブジェクトタイプに切り替えられたときは、当該第２オブジェクトタイプに関連付けられた前記オブジェクトを利用する前記イベントを発生させる処理を継続して行う、請求項１に記載の情報処理プログラム。
【請求項7】
前記イベント発生手段は、前記ユーザによる前記第１入力操作が複数回繰り返し行われている場合に、前記カウンタが前記基準範囲に含まれるようになったときは、前記第２オブジェクトタイプに関連付けられた前記オブジェクトを利用する前記イベントを発生させる処理を、一定の時間だけ停止した後に再開する、請求項１に記載の情報処理プログラム。
【請求項8】
前記イベント発生手段は、前記ユーザによる前記第１入力操作が複数回繰り返し行われている場合に、前記カウンタが前記基準範囲に含まれるようになったときは、前記第２オブジェクトタイプに関連付けられた前記オブジェクトを利用する前記イベントを発生させる処理を、前記ユーザによる前記第１入力操作が繰り返されなくなるまで停止した後に再開する、請求項１に記載の情報処理プログラム。
【請求項9】
前記イベント発生手段は、前記イベントを発生させる処理を一時的に停止している間に前記ユーザによる前記第１入力操作が停止したときは、前記第２オブジェクトタイプに関連付けられた前記オブジェクトを利用する当該イベントを発生させる処理を一時的に停止する時間を短くする、請求項１に記載の情報処理プログラム。
【請求項10】
前記ユーザによる第３入力操作が行われたことに応じて前記仮想空間内の位置を指示するカーソルを移動させるカーソル移動手段と、前記ユーザによる第４入力操作が行われたことに応じて前記カーソルが前記イベントの対象である対象オブジェクトの位置を指示するように当該カーソルを固定するカーソル固定手段として前記コンピュータを更に機能させ
前記イベント発生手段は、前記第１入力操作が行われるごとに、前記カーソルが指示する前記仮想空間内の前記位置に対して前記イベントを発生させる、請求項１に記載の情報処理プログラム。
【請求項11】
各々のオブジェクトに関連付けられたオブジェクトタイプの中から第１オブジェクトタイプを利用オブジェクトタイプとして決定するタイプ決定手段と、ユーザによる第１入力操作が行われたことを検出する検出手段と、
前記第１入力操作が１回行われる毎に前記利用オブジェクトタイプに関連付けられた前記オブジェクトを利用するイベントを発生させる処理を行うイベント発生手段と、
前記イベントが発生する毎に、当該利用オブジェクトタイプに対応付けられたカウンタを変化させるカウント変化処理を行うカウンタ変化手段と、
仮想空間を表す表示用画像を生成する画像生成手段とを備え、
前記タイプ決定手段は、前記利用オブジェクトタイプに対応付けられた前記カウンタが基準範囲に含まれるようになった場合に、前記利用オブジェクトタイプを前記第１オブジェクトタイプから第２オブジェクトタイプに切り替え、
前記イベント発生手段は、前記ユーザによる前記第１入力操作が複数回繰り返し行われている場合に、前記カウンタが前記基準範囲に含まれるようになったときは、前記第２オブジェクトタイプに関連付けられた前記オブジェクトを利用する前記イベントを発生させる処理を一時的に停止した後に再開する、情報処理装置。
【請求項12】
各々のオブジェクトに関連付けられたオブジェクトタイプの中から第１オブジェクトタイプを利用オブジェクトタイプとして決定するタイプ決定手段と、ユーザによる第１入力操作が行われたことを検出する検出手段と、
前記第１入力操作が１回行われる毎に前記利用オブジェクトタイプに関連付けられた前記オブジェクトを利用するイベントを発生させる処理を行うイベント発生手段と、
前記イベントが発生する毎に、当該利用オブジェクトタイプに対応付けられたカウンタを変化させるカウント変化処理を行うカウンタ変化手段と、
仮想空間を表す表示用画像を生成する画像生成手段とを備え、
前記タイプ決定手段は、前記利用オブジェクトタイプに対応付けられた前記カウンタが基準範囲に含まれるようになった場合に、前記利用オブジェクトタイプを前記第１オブジェクトタイプから第２オブジェクトタイプに切り替え、
前記イベント発生手段は、前記ユーザによる前記第１入力操作が複数回繰り返し行われている場合に、前記カウンタが前記基準範囲に含まれるようになったときは、前記第２オブジェクトタイプに関連付けられた前記オブジェクトを利用する前記イベントを発生させ
る処理を一時的に停止した後に再開する、情報処理システム。
【請求項13】
情報処理装置のコンピュータに実行させる情報処理方法であって、前記コンピュータに、
各々のオブジェクトに関連付けられたオブジェクトタイプの中から第１オブジェクトタイプを利用オブジェクトタイプとして決定させ、
ユーザによる第１入力操作が行われたことを検出させ、
前記第１入力操作が１回行われる毎に前記利用オブジェクトタイプに関連付けられた前記オブジェクトを利用するイベントを発生させる処理を行わせ、
前記イベントが発生する毎に、当該利用オブジェクトタイプに対応付けられたカウンタを変化させるカウント変化処理を行わせ、
仮想空間を表す表示用画像を生成させ、
前記利用オブジェクトタイプの決定において、当該利用オブジェクトタイプに対応付けられた前記カウンタが基準範囲に含まれるようになった場合に、当該利用オブジェクトタイプを前記第１オブジェクトタイプから第２オブジェクトタイプに切り替え、
前記イベントを発生させる処理において、前記ユーザによる前記第１入力操作が複数回繰り返し行われている場合に、前記カウンタが前記基準範囲に含まれるようになったときは、前記第２オブジェクトタイプに関連付けられた前記オブジェクトを利用する前記イベントを発生させる処理を一時的に停止した後に再開する、情報処理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ある入力操作が繰り返し行われているときのゲーム処理の制御に関する。
【背景技術】
【0002】
従来から、複数の種類がある第１オブジェクトを投擲する操作を行うことが可能なゲームが知られている（例えば非特許文献１）。当該ゲームでは、投擲操作に割り当てられているボタンを連打することで、連続して第１オブジェクトを投擲できる。また、投擲可能な第１オブジェクト数は、プレイヤキャラクタのグループに加わっている第１オブジェクトの数が上限となっている。そして、連続して第１オブジェクトを投擲している場合は、種類毎に投擲される。例えば、種類Ａ、種類Ｂ、種類Ｃの第１オブジェクトがそれぞれ１０体ずつ上記グループ内にいる場合を想定する。この場合、上記ボタンの連打によって投擲すると、種類Ａの第１オブジェクトが１体ずつ投擲されていき、１０体全て投擲し終わると、投擲する対象が種類Ｂの第１オブジェクトに自動的に切り替わり、引き続き投擲が継続される。つまり、ユーザは、単に連打を続けているだけで、種類Ａを１０体→種類Ｂを１０体→種類Ｃを１０体、というように、グループ内の第１オブジェクトの投擲を連続的に行うことができる。
【先行技術文献】
【非特許文献】
【0003】
【文献】任天堂株式会社、”Ｐｉｋｍｉｎ ３ Ｄｅｌｕｘｅ”、［online］、［令和４年６月２２日検索］、インターネット（ＵＲＬ：https://www.nintendo.com/store/products/pikmin-3-deluxe-switch/）
【発明の概要】
【発明が解決しようとする課題】
【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】
【図1】本体装置２に左コントローラ３および右コントローラ４を装着した状態の一例を示す図
【図2】本体装置２から左コントローラ３および右コントローラ４をそれぞれ外した状態の一例を示す図
【図3】本体装置２の一例を示す六面図
【図4】左コントローラ３の一例を示す六面図
【図5】右コントローラ４の一例を示す六面図
【図6】本体装置２の内部構成の一例を示すブロック図
【図7】本体装置２と左コントローラ３および右コントローラ４との内部構成の一例を示すブロック図
【図8】本実施形態に係るゲーム画面の一例
【図9】本実施形態に係るゲーム画面の一例
【図10】本実施形態に係るゲーム画面の一例
【図11】本実施形態に係るゲーム画面の一例
【図12】本実施形態に係るゲーム画面の一例
【図13】本実施形態に係るゲーム画面の一例
【図14】本実施形態に係るストッパー制御の概要を説明するための図
【図15】本実施形態に係るゲーム画面の一例
【図16】本実施形態に係るゲーム画面の一例
【図17】本実施形態に係るゲーム画面の一例
【図18】本実施形態に係るゲーム画面の一例
【図19】本実施形態に係るゲーム画面の一例
【図20】本実施形態に係るゲーム画面の一例
【図21】本実施形態に係るゲーム画面の一例
【図22】ＤＲＡＭ８５に記憶される各種データの一例を示すメモリマップ
【図23】ＰＣデータ３０２の一例
【図24】サポーター種類マスタデータ３０３の一例
【図25】サポーターデータ３０４の一例
【図26】仕事対象データ３０５の一例
【図27】操作データ３１０の一例
【図28】本実施形態に係るゲーム処理の詳細を示すフローチャート
【図29】プレイヤキャラクタ制御処理の詳細を示すフローチャート
【図30】カーソル制御処理の詳細を示すフローチャート
【図31】カーソル制御処理の詳細を示すフローチャート
【図32】連投ストッパー制御処理の詳細を示すフローチャート
【図33】ストッパー発動処理の詳細を示すフローチャート
【図34】ストッパー発動処理の詳細を示すフローチャート
【図35】ストッパー解除処理の詳細を示すフローチャート
【図36】投擲処理の詳細を示すフローチャート
【図37】投擲処理の詳細を示すフローチャート
【図38】連打状態解除処理の詳細を示すフローチャート
【図39】サポーター制御処理の詳細を示すフローチャート
【図40】サポーター制御処理の詳細を示すフローチャート
【発明を実施するための形態】
【0029】
以下、一実施形態について説明する。
【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】
次に、ステップＳ８３で、プロセッサ８１は、隊列内の現在の投擲対象種類の中から、投擲対象サポーターを１体選択する（当該選択手法はどのような手法でもよい）。
【0174】
次に、ステップＳ８４で、プロセッサ８１は、投擲対象として選択したサポーターに係る行動パラメータ３４６の内容を設定する。当該パラメータは、投擲先の仕事対象やカーソル２０２の位置に応じて適宜設定され得る。具体的には、着地点や上述した「持ち場」の位置、これを踏まえた移動軌跡等が、移動に関するパラメータとして設定される。また、投擲先の仕事対象に応じて、サポーターが取る行動内容（運搬アクション、破壊アクション等）を示す各種のパラメータが設定される。
【0175】
次に、ステップＳ８５で、プロセッサ８１は、投擲対象サポーターに対応するサポーター行動状態３４５に「仕事待機中」を設定する。
【0176】
次に、ステップＳ８６で、プロセッサ８１は、カーソル２０２が「必要力設定型」の仕事対象を指示しているか否かを判定する。すなわち、ターゲットが運搬物オブジェクトであるか否かが判定される。当該判定の結果、指示している場合は（ステップＳ８６でＹＥＳ）、ステップＳ８７で、プロセッサ８１は、ターゲットの待機力情報３５５に、投擲対象となったサポーターの仕事力を加算する。本例では、赤、青、黄サポーターが投擲対象だった場合は”１”が加算され、白サポーターが投擲対象だった場合は”１０”が加算されることになる。
【0177】
一方、上記ステップＳ８６の判定の結果、カーソル２０２が「必要力設定型」の仕事対象を指示していない場合は（ステップＳ８６でＮＯ）、「必要力非設定型」の仕事対象がターゲットであるため（本例では障害物オブジェクト）、上記ステップＳ８７の処理はスキップされる。
【0178】
次に、図３７のステップＳ８８で、プロセッサ８１は、投擲対象となったサポーター種類の隊列内の残数が１つ減るように、隊列情報３２３の内容を更新する。例えば、赤サポーターを１体、投擲する場合は、隊列内の赤サポーターの残数が１つ減るように、ＰＣデータ３０２の隊列情報３２３の内容が更新される（例えば、赤サポーターの残数を示すカウンタを減らす）。
【0179】
次に、ステップＳ８９で、プロセッサ８１は、隊列情報３２３を参照し、現在の投擲対象種類に係るサポーターの隊列内の残数が０になったか否かを判定する。当該判定の結果、０になった場合は（ステップＳ８９でＹＥＳ）、ステップＳ９０で、プロセッサ８１は、投擲対象種類の自動切り替えを行う。具体的には、プロセッサ８１は、予め定義された順番に基づいて、次の投擲対象種類を選択する。そして、プロセッサ８１は、選択した種類を示す情報を、上記投擲対象種類データ３０６の中央枠情報３０７に設定する。また、これに伴い、プロセッサ８１は、右枠情報３０８および左枠情報３０９も更新する。
【0180】
一方、上記判定の結果、上記残数が０ではない場合は（ステップＳ８９でＮＯ）、上記ステップＳ９０の処理はスキップされる。以上で、投擲処理は終了する。
【0181】
図２９に戻り、次に、上記ステップＳ１３の判定の結果、投擲操作が行われていないと判定された場合の処理について説明する。この場合は、ステップＳ１９で、プロセッサ８１は、現在が連打状態であって、連打状態を解除する条件が満たされたか否かを判定する。つまり、ユーザがＡボタン５３の連打を止めた直後の状態か否かを判定する。本実施形態では、前回のＡボタン５３の入力から、Ａボタン５３の入力が無いまま１１フレーム以上経過した場合に、連打状態を解除する条件が満たされたと判定する。当該判定の結果、上記解除条件が満たされていない場合は（ステップＳ１９でＮＯ）、後述のステップＳ１７に処理が進められる。
【0182】
一方、上記判定の結果、解除条件が満たされた場合は（ステップＳ１９でＹＥＳ）、ステップＳ２０で、プロセッサ８１は、連打状態解除処理を実行する。図３８は、当該連打状態解除処理の詳細を示すフローチャートである。図３８において、まず、ステップＳ１０１で、プロセッサ８１は、連打状態フラグ３２５にオフを設定する。次に、ステップＳ１０２で、プロセッサ８１は、発動済みフラグ３３０にもオフを設定する。次に、ステップＳ１０３で、プロセッサ８１は、ストッパーフラグ３２９がオンか否かを判定する。つまり、ストッパー発動中に（１秒経過する前に）ユーザがＡボタン５３の連打を止めたか否かを判定する。オンの場合は（ステップＳ１０３でＹＥＳ）、ステップＳ１０４で、プロセッサ８１は、ストッパーフラグ３２９にオフを設定する。一方、上記判定の結果、オフの場合は（ステップＳ１０３でＮＯ）、当該ステップＳ１０４の処理はスキップされる。以上で、連打状態解除処理は終了する。
【0183】
図２９に戻り、次に、ステップＳ１７で、プロセッサ８１は、操作データ３１０に基づいたＰＣ２０１の移動制御を行う。具体的には、ＰＣ位置・姿勢情報３２１やＰＣ移動パラメータ３２２の内容が更新される。
【0184】
次に、ステップＳ１８で、プロセッサ８１は、操作データ３１０に基づいた、上記以外のＰＣ２０１の動作制御処理を実行する。例えば、隊列にサポーターを追加するための処理や、手動切り替え操作によって投擲対象種類を切り替える処理が行われる。その後、プロセッサ８１は、プレイヤキャラクタ制御処理を終了する。
【0185】
［サポーターの動作制御］
図２８に戻り、次に、ステップＳ３で、プロセッサ８１は、サポーター制御処理を実行する。これは、各サポーターの動作を制御するための処理である。図３９～図４０は、当該サポーター制御処理の詳細を示すフローチャートである。図３９において、まず、ステップＳ１１１で、プロセッサ８１は、以下の処理の対象とするサポーターを１体選択する。以下、当該選択されたサポーターのことを、処理対象サポーターと呼ぶ。
図２８に戻り、次に、ステップＳ３で、プロセッサ８１は、サポーター制御処理を実行する。これは、各サポーターの動作を制御するための処理である。図３９～図４０は、当該サポーター制御処理の詳細を示すフローチャートである。図３９において、まず、ステップＳ１１１で、プロセッサ８１は、以下の処理の対象とするサポーターを１体選択する。以下、当該選択されたサポーターのことを、処理対象サポーターと呼ぶ。
【0186】
次に、ステップＳ１１２で、プロセッサ８１は、処理対象サポーターのサポーター行動状態３４５が「仕事待機中」か否かを判定する。「仕事待機中」の場合は（ステップＳ１１２でＹＥＳ）、ステップＳ１１３で、プロセッサ８１は、処理対象サポーターのサポーター位置・姿勢情報３４３等に基づき、投擲されてから着地済みであるか否か判定する。当該判定の結果、投擲された後、まだ着地していない場合は（ステップＳ１１３でＮＯ）、ステップＳ１１４で、プロセッサ８１は、処理対象サポーターの行動パラメータ３４６に基づき移動させる。本例では、行動パラメータ３４６には、投擲中は放物線を描く軌道で移動するようなパラメータが設定されているものとする。その後、後述のステップＳ１２４に処理が進められる。
【0187】
一方、上記ステップＳ１３の判定の結果、着地済みの場合は（ステップＳ１１３でＹＥＳ）、ステップＳ１１５で、プロセッサ８１は、処理対象サポーターが上述したような持ち場についたか否かをサポーター位置・姿勢情報３４３等に基づき判定する。持ち場についていない場合は（ステップＳ１１５でＮＯ）、ステップＳ１２０で、プロセッサ８１は、処理対象サポーターを持ち場に向けて移動させる。その後、後述のステップＳ１２４に処理が進められる。一方、持ち場についた場合は（ステップＳ１１５でＹＥＳ）、ステップＳ１１６で、プロセッサ８１は、サポーター行動状態３４５に「仕事中」を設定する。次に、ステップＳ１１７で、プロセッサ８１は、処理対象サポーターのアクションの対象となる仕事対象に応じて、行動パラメータ３４６を設定する。例えば、仕事対象が上記運搬物オブジェクトであれば、運搬アクションを行うように行動パラメータ３４６が設定される。また、仕事対象が上記障害物オブジェクトであれば、破壊アクションを行うように行動パラメータ３４６が設定される。
【0188】
次に、ステップＳ１１８で、プロセッサ８１は、処理対象サポーターのアクション対象である仕事対象が、「必要力設定型」か否かを判定する。当該判定の結果、「必要力設定型」の場合は（ステップＳ１１８でＹＥＳ）、ステップＳ１１９で、プロセッサ８１は、当該仕事対象の待機力情報３５５から１を減算し、稼働力情報３５４に１を加算する。一方、上記判定の結果、「必要力設定型」ではない場合は（ステップＳ１１８でＮＯ）、上記ステップＳ１１９の処理はスキップされ、後述のステップＳ１２４に処理が進められる。
【0189】
次に、上記ステップＳ１１２の判定の結果、「仕事待機中」ではない場合（ステップＳ１１２でＮＯ）の処理について説明する。この場合は、図４０のステップＳ１２１で、プロセッサ８１は、処理対象サポーターのサポーター行動状態３４５が「仕事中」か否かを判定する。当該反映の結果、「仕事中」の場合は（ステップＳ１２１でＹＥＳ）、ステップＳ１２２で、プロセッサ８１は、その処理対象サポーターの行動パラメータ３４６に基づき、当該処理対象サポーターの動作を制御する。例えば、運搬アクションや破壊アクションに係る動作制御が行われることになる。ここで、上記運搬アクションに関して補足すると、サポーターが持ち場についたが、必要仕事力がまだ充足されていない場合は、運搬物オブジェクトを持ち上げようとする動作が運搬アクションの一環として行われる。
【0190】
一方、上記判定の結果、「仕事中」ではない場合は（ステップＳ１２１でＮＯ）、ステップＳ１２３で、プロセッサ８１は、サポーター行動状態３４５の内容に応じたその他の動作制御を行う。例えば、サポーター行動状態３４５が「待機中」であれば、辺りを見回すような動作をサポーターに行わせる。
【0191】
次に、図３９のステップＳ１２４で、プロセッサ８１は、全てのサポーターについて、上記のような処理を行ったか否かを判定する。まだ未処理のサポーターが残っている場合は（ステップＳ１２４でＮＯ）、上記ステップＳ１１１に戻り、処理が繰り返される。全てのサポーターについて処理した場合は（ステップＳ１２４でＹＥＳ）、プロセッサ８１は、当該サポーター制御処理を終了する。
【0192】
［その他のオブジェクトの制御］
図２８に戻り、次に、ステップＳ４で、プロセッサ８１は、上記ＰＣ２０１およびサポーター以外の各種のオブジェクトの動作制御を行う。例えば、敵キャラクタの動作を制御したり、運搬物オブジェクトを運搬に伴って移動させたり、障害物オブジェクトが破壊される様子を示すアニメーションを再生したりする。
図２８に戻り、次に、ステップＳ４で、プロセッサ８１は、上記ＰＣ２０１およびサポーター以外の各種のオブジェクトの動作制御を行う。例えば、敵キャラクタの動作を制御したり、運搬物オブジェクトを運搬に伴って移動させたり、障害物オブジェクトが破壊される様子を示すアニメーションを再生したりする。
【0193】
［仕事力状況画像の設定］
次に、ステップＳ５で、プロセッサ８１は、上記仕事力状況画像２０５の表示内容を更新する。当該処理は、上記仕事力状況画像２０５の表示が必要な場合に適宜実行される。本実施形態では、仕事力状況画像２０５は、必要仕事力が”２”以上の運搬物オブジェクトに関して表示される（上記のように、障害物オブジェクトや、必要仕事力が”１”の運搬物オブジェクトについては表示されない）。そのため、当該処理では、このような運搬物オブジェクトについて、上記必要仕事力情報３５３および稼働力情報３５４に基づいて上記仕事力状況画像２０５が生成される、または、その表示内容の更新が行われる。
次に、ステップＳ５で、プロセッサ８１は、上記仕事力状況画像２０５の表示内容を更新する。当該処理は、上記仕事力状況画像２０５の表示が必要な場合に適宜実行される。本実施形態では、仕事力状況画像２０５は、必要仕事力が”２”以上の運搬物オブジェクトに関して表示される（上記のように、障害物オブジェクトや、必要仕事力が”１”の運搬物オブジェクトについては表示されない）。そのため、当該処理では、このような運搬物オブジェクトについて、上記必要仕事力情報３５３および稼働力情報３５４に基づいて上記仕事力状況画像２０５が生成される、または、その表示内容の更新が行われる。
【0194】
［ゲーム画像の出力］
次に、ステップＳ６で、プロセッサ８１は、上記ステップＳ２～Ｓ５の処理内容を反映したゲーム画像を生成して、上記据え置き型モニタ等に出力する。
次に、ステップＳ６で、プロセッサ８１は、上記ステップＳ２～Ｓ５の処理内容を反映したゲーム画像を生成して、上記据え置き型モニタ等に出力する。
【0195】
次に、ステップＳ７で、プロセッサ８１は、ゲーム処理の終了条件が満たされたか否かを判定する。例えば、ユーザによるゲーム終了指示操作があったか否かを判定する。その結果、終了条件が満たされていなければ（ステップＳ７でＮＯ）、上記ステップＳ２に戻り、処理が繰り返される。終了条件が満たされていれば（ステップＳ７でＹＥＳ）、プロセッサ８１は、当該ゲーム処理を終了する。
【0196】
以上で、本実施形態に係るゲーム処理の詳細説明を終了する。
【0197】
このように、本実施形態では、「必要数設定型」の仕事対象については、必要仕事力を満たした時点（投擲操作が行われた時点）で、投擲に係るＰＣ２０１の動作を一旦停止させる。また、その後も連打が続いている場合は、１秒経過した後、投擲動作を再開させている。そのため、必要数以上の投擲が行われることを抑制しつつ、必要数に達するまでは連打による操作性を確保できる。これにより、操作性を向上できる。
【0198】
また、「種類制限型」の仕事対象に関して、投擲対象種類の自動切り替えが発生した場合も、投擲に係るＰＣ２０１の動作を一旦停止させている。そのため、自動切り替えの発生に気付かずに連打の勢いでサポーターの投擲が継続した結果、有用ではないサポーターまで（勢いで）投擲してしまい、ユーザにとって不利な展開に陥ることを防ぐことができる。また、自動切り替えが発生するまでは連打操作できるため、操作のテンポが悪くならないようにしている。これにより、ユーザの利便性および操作性を向上できる。
【0199】
［変形例］
なお、上記実施形態では、ストッパー発動後、（連打状態のまま）１秒経過後にストッパーを解除するという例を挙げた。この”１秒”というのはあくまで一例であり、他の時間を用いてもよいし、秒数ではなく、例えば、”ストッパー発動からｎフレーム後”のような指標を用いてもよい。
なお、上記実施形態では、ストッパー発動後、（連打状態のまま）１秒経過後にストッパーを解除するという例を挙げた。この”１秒”というのはあくまで一例であり、他の時間を用いてもよいし、秒数ではなく、例えば、”ストッパー発動からｎフレーム後”のような指標を用いてもよい。
【0200】
また、他の実施形態では、ストッパーの発動後、時間経過で解除せずに、連打状態が続いている間はストッパーを発動させ続けるようにしてもよい。この場合は、連打状態が終わると共に、ストッパーを解除すればよい。
【0201】
また、ストッパー発動中の制御として、上記実施形態では、ＰＣ２０１に投擲動作を行わせないような制御例を挙げた。この他、例えば、Ａボタン５３の入力そのものを受け付けなくする（Ａボタン５３の入力を無視する）ような制御を行ってもよい。あるいは、ＰＣ２０１に投擲にかかるアニメーションは再生させるが、実際のサポーターの投擲を行わないようにしてもよい。この場合も、ユーザに違和感を与え、運搬についての必要数到達や、投擲対象種類の残数切れについて注意喚起できる。
【0202】
また、投擲対象種類の自動切り替えによるストッパー発動に際して、上記実施形態では、保留条件を判定する例を挙げた。また、当該保留条件について、上記のような、現在のターゲットが「種類無制限型」か「種類制限型」かに基づいて判定する例を示した。この他、保留条件については、次のような条件を用いてもよい。まず、投擲対象種類が特定のサポーター種類ではないことを保留条件としてもよい。換言すれば、次に投擲する投擲対象種類が特定の種類のサポーターである場合に、ストッパーを発動させるよう制御してもよい。例えば、図示は省略するが、仕事力が”１００”の特殊なサポーターが１体、隊列内に存在している場合を想定する。このような特殊サポーターは、それ１体だけで、どの仕事対象についても必要仕事力を満たすようなサポーターであり、その影響力が高いものである。このような特殊なサポーターは、その影響力の高さ故に、軽々しく投擲したくない（使用したくない）、というユーザのニーズがあることも想定される。そのため、現在のターゲットが「種類無制限型」か「種類制限型」に関わらず、投擲対象種類がこのような特殊なサポーターに切り替わったときにストッパーを発動させるようにしてもよい。これにより、このような特殊なサポーターが、連打操作の勢いでユーザの意図に反して投擲されないようにすることができる。
【0203】
また、他の保留条件として、投擲対象種類とターゲットとの組み合わせが所定の組み合わせであることを保留条件としてもよい。例えば、仕事対象が「種類制限型」であり、上記自動切り替えの発生時に、当該仕事対象に設定されている仕事可能種類と投擲対象種類とが一致していない場合はストッパーを発動させ、一致している場合はストッパーを発動させないようにしてもよい。上記の電気ゲートの例で言うと、結果的には上記と同じ結果となるが、自動切り替えが発生したときに、（次の）投擲対象種類が黄サポーターであるか否かを判定してもよい。そして、黄サポーターの場合は、保留条件を満たすとしてストッパーは発動させず、黄サポーター以外の場合は、保留条件を満たさないとして、ストッパーを発動させるような制御を行ってもよい。
【0204】
また、上記の例では、運搬物オブジェクトについては、全て「種類無制限型」である場合を例に説明していた。他の実施形態では、運搬物オブジェクトについても「種類制限型」のものを設けてもよい。そして、この場合に、上記必要仕事力の充足に基づいたストッパーと、投擲対象種類の自動切り替えによるストッパーとが併存するようにしてもよい。
例えば、「赤および黄サポーターのみ運搬可能であり、必要仕事力が”２０”の運搬物オブジェクト」というものを設けてもよい。この場合は、上記自動切り替えが発生した際に１度目のストッパーを発動させ、その後、必要仕事力が充足された時点で２度目のストッパーを発動させるようにしてもよい。あるいは、どちらか一方だけを発動させるようにしてもよい。
例えば、「赤および黄サポーターのみ運搬可能であり、必要仕事力が”２０”の運搬物オブジェクト」というものを設けてもよい。この場合は、上記自動切り替えが発生した際に１度目のストッパーを発動させ、その後、必要仕事力が充足された時点で２度目のストッパーを発動させるようにしてもよい。あるいは、どちらか一方だけを発動させるようにしてもよい。
【0205】
また、投擲対象種類の自動切り替えによるストッパー発動の発動回数について、上記実施形態では、１連打期間中に１回のみという例を示した。他の実施形態では、当該ストッパーについては、１回だけでなく、１連打期間中において、投擲対象種類の自動切り替えが発生する度に発動させるようにしてもよい。
【0206】
また、投擲対象種類の自動切り替えによるストッパー発動に関して、上記実施形態では、仕事対象が「種類制限型」であるか「種類無制限型」であるかによって、ストッパーを発動するか否かを使い分ける例を挙げた。この点について、他の実施形態では、「種類制限型」、「種類無制限型」のような分類は行わず、例えば、上記「種類無制限型」に該当する仕事対象について、上述した「ストッパー無効」の属性を持たせるような構成としてもよい。つまり、投擲対象種類の自動切り替えが発生しても、仕事対象が「ストッパー無効」の属性を有していれば、ストッパーを発動させないような制御を行ってもよい。
【0207】
また、上記実施形態では、現在の投擲対象種類の残数が０になったときに投擲対象種類の自動切り替えを行い、必要に応じてストッパーを発動させる例を挙げた。この他、他の実施形態では、自動切り替えが行われたタイミングでは無く、現在の投擲対象種類の残数が例えば”０～２”のような所定の範囲内の値に含まれるようになったことに応じて、ストッパーを発動させるような制御としてもよい。これは、例えば、所定のアイテムの使用等によって、ＰＣ２０１が一時的に、１回の投擲動作で２体のサポーターを１度に投擲できるようになるギミックがある場合等に有用である。この場合は、残数が０になりそうなときにストッパーを発動させることで、現在の投擲対象種類の残数が残り少ないことにユーザを気付かせることができる。つまり、残数が０になる前の時点で、事前にユーザに気付きを与えることができる。
【0208】
また、上記実施形態では、仕事力状況画像２０５の一例として、「稼働力／必要仕事力」という形式で表示する例を示した。このような数値を使った表示形式に限らず、他の実施形態では、例えばゲージ画像等のインジケータを用いて充足状況を表示するようにしてもよい。また、その他、数値やインジケータは表示せず、上記持ち場についたサポーターのアイコン画像を充足分の数だけ表示してもよい。
【0209】
また、上記実施形態では、上記投擲操作を繰り返す操作例として、Ａボタン５３を連打する操作を一例に挙げた。このようなボタン操作に限らず、モーションセンサを用いた入力方法による繰り返し入力の場合でも、上記の処理は適用できる。この場合は、１回分のボタン操作の代わりに、例えばコントローラを１回振る操作を利用してもよい。
【0210】
また、上記実施形態においては、ゲーム処理に係る一連の処理を単一の本体装置２で実行される場合を説明した。他の実施形態においては、上記一連の処理が複数の情報処理装置からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの一部の処理がサーバ側装置によって実行されてもよい。更には、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。また、いわゆるクラウドゲーミングの構成としてもよい。例えば、本体装置２は、ユーザの操作を示す操作データを所定のサーバに送り、当該サーバにおいて各種ゲーム処理が実行され、その実行結果が動画・音声として本体装置２にストリーミング配信されるような構成としてもよい。
【符号の説明】
【0211】
１ ゲームシステム
２ 本体装置
３ 左コントローラ
４ 右コントローラ
８１ プロセッサ
８４ フラッシュメモリ
８５ ＤＲＡＭ
２ 本体装置
３ 左コントローラ
４ 右コントローラ
８１ プロセッサ
８４ フラッシュメモリ
８５ ＤＲＡＭ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図40】
