JP7474234B2 - 情報処理システム、情報処理プログラム、情報処理装置、および情報処理方法 - Google Patents

Description

本開示は、スポーツに関するゲームを実行する情報処理に関する。

従来から、選手が前衛と後衛とに分かれてゲームを進行させる球技ゲームが知られている（例えば非特許文献１）。

任天堂株式会社、"Ｗｉｉスポーツクラブ テニス"、［online］、［令和３年１１月９日検索］、インターネット（ＵＲＬ：https://www.nintendo.co.jp/wiiu/awsj/tennis/index.html）

上記のような球技（具体的にはテニス）ゲームでは、一旦ゲーム（ボールのラリー）が開始すれば、得点が入るまでは、前衛と後衛との交代は起こらないものとなっている。例えば、サーブを打ってゲームが開始すれば、同一のゲーム（ラリーが中断するまでの期間）においては、前衛と後衛は交代しない。そのため、ユーザは、このゲーム中は、前衛または後衛として、その役割に沿ったプレイを行うことになる。

この点について、同一のゲーム中に、ユーザの役割を多様なものとすることで、ゲームの興趣性を向上させる余地があった。

それ故に、本開示における目的は、ゲーム内における役割が、ゲーム展開に応じて順次割り当てられていく新規な球技ゲームを実行可能な情報処理システム、情報処理プログラム、情報処理装置、情報処理方法を提供することである。

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

構成例の一例は、操作装置と、プロセッサを備える情報処理装置とを含む情報処理システムである。操作装置は、少なくとも、慣性センサーと、慣性センサーの出力に基づく操作データを情報処理装置に送信するデータ送信部とを備える。プロセッサは、少なくとも、以下の処理を実行する。仮想空間内の移動オブジェクトと、ユーザの操作対象であるユーザキャラクタと、味方キャラクタと、敵キャラクタとを含むキャラクタオブジェクトを用いたスポーツに関するゲームを実行する。ユーザキャラクタと味方キャラクタとを仮想空間の第１領域に配置し、敵キャラクタを当該仮想空間の第２領域に配置する。ユーザキャラクタに、移動オブジェクトを第１領域において移動させる役割、または、移動オブジェクトを第２領域に向けて移動させる役割を少なくとも含む複数の役割のうち、１つの役割をゲームの進行に応じて所定の順番で割り当てる。所定の役割が割り当てられているユーザキャラクタを、当該所定の役割と、移動オブジェクトの移動方向とに基づいて、第１領域内において自動的に移動させる。ユーザキャラクタに所定の役割が割り当てられている場合であって、データ送信部から取得した操作データが当該所定の役割に対応した条件を満たす場合、当該所定の役割と当該操作データとに基づく当該ユーザキャラクタのアクションによって移動オブジェクトを移動させる。

上記構成例によれば、移動オブジェクトを移動させるゲームにおいて、ユーザキャラクタおよび味方キャラクタの役割を所定の順番で順次割り当てる制御を行っている。これにより、ユーザキャラクタの役割を多様なものとし、また、その役割に応じた操作をユーザに行わせることができる。これにより、ユーザは様々な役割を担当してプレイすることができ、ゲームの興趣性を向上させることができる。

他の構成例として、操作装置は、方向入力部を更に備えていてもよい。また、操作データは、当該方向入力部の出力を更に含んでいてもよい。そして、プロセッサは、ユーザキャラクタに所定の役割が割り当てられている場合、方向出力部の出力と当該所定の役割とに基づいてユーザキャラクタを移動させてもよい。

上記構成例によれば、ユーザキャラクタについて、自動的な移動の他、ユーザの直接的な方向入力操作に基づいて移動させることができる。これにより、ユーザ自身で第１領域内における位置取り等を行わせることもでき、ゲームの興趣性を向上できる。

他の構成例として、方向出力部の出力に基づく移動は、移動オブジェクトが第２領域内にあるときに可能としてもよい。

上記構成例によれば、移動オブジェクトが第２領域内にある場合、ユーザオブジェクトを方向入力操作に基づいて移動可能とすることができる。これにより、例えば、移動オブジェクトが第１領域内に入ってくるのを待ち受けるような状態のときは、ユーザの操作に基づいて位置取りを行わせることができる。また、移動オブジェクトが第１領域内にある状態では、移動については自動的な制御に任せ、ユーザがそのときの役割に応じた操作に集中しやすい状況を作り出すことができる。

他の構成例として、複数の役割のうち１つの役割は、移動オブジェクトとの位置関係に関わらず、ユーザキャラクタに割り当てられてもよい。

上記構成例によれば、キャラクタと移動オブジェクトとの位置関係にかかわらず、所定の順番で役割が割り当てられる。これにより、様々な役割を万遍なくユーザに体験させ、ゲームの興趣性を向上することができる。

他の構成例として、ユーザキャラクタに関する所定の順番は、移動オブジェクトを第１領域に向けて移動させる役割が割り当てられた敵キャラクタが当該役割に基づく所定のアクションを行ったときに決定されてもよい。

上記構成例によれば、ゲーム展開に応じて、より適切に役割の割り当てを決定できる。

他の構成例として、プロセッサは、更に、敵キャラクタの位置に少なくとも基づいて、ユーザキャラクタを自動的に移動させてもよい。

上記構成例によれば、例えば、敵キャラクタの所定のアクションによって移動されてくる移動オブジェクトを受ける役割がユーザキャラクタに割り当てられている場合、敵キャラクタの位置に応じて、役割を果たすのに有利な位置に自動的に移動させることができる。これにより、ユーザは、ユーザキャラクタのアクションを実行させる操作に集中することができ、割り当てられた役目を果たしやすい状態とすることができる。

他の構成例として、プロセッサは、更に、味方キャラクタの位置に少なくとも基づいてユーザキャラクタを自動的に移動させてもよい。

上記構成例によれば、味方キャラクタの位置も考慮してユーザキャラクタを自動的に移動させることができる。これにより、割り当てられた役目を果たしやすい状態とすることができる。また、チームの一員として、味方キャラクタと連携してプレイしているようなプレイ感を提供することができる。

他の構成例として、プロセッサは、ユーザキャラクタに第１役割が割り当てられている場合、第１領域に向かって移動する移動オブジェクトと当該ユーザキャラクタとの位置関係が所定の条件を満たす場合、当該移動オブジェクトの移動方向を第２領域に向かう方向に変更させてもよい。

上記構成例によれば、ユーザがタイミング良く所定の操作を行うことで、敵キャラクタのアクションによって第１領域に向けて移動させられた移動オブジェクトを跳ね返して第２領域に移動させるようなアクションをユーザキャラクタに行わせることができる。これにより、ゲームの興趣性を向上できる。

他の構成例として、プロセッサは、ユーザキャラクタに第２役割が割り当てられている場合であって、操作装置が第１タイミングにおいて所定の姿勢で振られたことを操作データが示す場合、当該操作データに基づいて移動オブジェクトを前記第２領域へ向けて移動させてもよい。

上記構成例によれば、第２役割のときにユーザがタイミング良く操作装置を振る操作を行うことで、移動オブジェクトを第２領域に打ち込むようなアクションをユーザキャラクタに行わせることができる。

他の構成例として、プロセッサは、ユーザキャラクタに第２役割が割り当てられている場合であって、操作装置が第１タイミングよりも速い第２タイミングにおいて所定の姿勢で振られたことを操作データが示す場合、当該操作データに基づいて移動オブジェクトを第２領域へ向けて移動させてもよい。

上記構成例によれば、移動オブジェクトを第２領域に打ち込むようなアクションをユーザキャラクタに実行させるに際して、複数の実行タイミングをユーザに提供することができ、どのタイミングで実行するかをユーザの選択に委ねることで、ゲームの戦略性を高め、興趣性を向上できる。

他の構成例として、情報処理システムは、第２情報処理装置を更に含んでいてもよい。更に、敵キャラクタ、または、味方キャラクタは、当該第２情報処理装置のユーザの操作対象として設定されてもよい。そして、プロセッサは、移動オブジェクトを第１領域内において移動させる役割、または、移動オブジェクトを第２領域に向けて移動させる役割を少なくとも含む複数の役割のうち、１つの役割をゲームの進行に応じて所定の順番でユーザキャラクタに割り当ててもよい。

上記構成例によれば、チームの一員としてプレイしているようなユーザ体験を提供できる。

他の構成例として、プロセッサは、更に、ユーザキャラクタに割り当てられた役割をユーザに示す通知画像を表示させてもよい。

上記構成例によれば、役割が次々に変更されていくゲーム展開において、ユーザに、次に自身が果たすべき役割や、どの役割の操作を行うべきかについて把握させることができる。これにより、ユーザが次に行うべき操作について混乱することを防ぐことができる。

他の構成例として、プロセッサは、ユーザキャラクタに割り当てられる役割が変更されたときに、通知画像を表示してもよい。

上記構成例によれば、役割が変更されたときに、次の役割が通知されるため、ユーザが次にどの役割で動くべきかについて速やかに把握させることができる。

他の構成例として、プロセッサは、所定の役割がユーザキャラクタに割り当てられた後、当該役割に対応する操作を行うべきタイミングよりも前のタイミングで通知画像を表示してもよい。

上記構成例によれば、例えば、役割が変更された後、その役割に対応する操作を行うべきタイミングの少し前等、より適切なタイミングで通知画像を表示することができる。

他の構成例として、プロセッサは、ユーザキャラクタおよび味方キャラクタが属する味方チームと、敵キャラクタが属する敵チームとで、不利なゲーム展開となっているチームに属するキャラクタオブジェクトの移動速度を増加させさせてもよい。

上記構成例によれば、劣勢側に有利になるよう調整するので、ゲームが一方的な展開となることを防ぎ、ゲームの興趣性が低下することを防ぐことができる。

他の構成例として、プロセッサは、第１領域および第２領域間における移動オブジェクトの移動回数の増加に応じて、当該移動オブジェクトの移動速度を増加させてもよい。

上記構成例によれば、例えば移動オブジェクトを第１領域と第２領域との間でラリーさせる回数に応じて、当該移動オブジェクトの移動速度が上がり、ゲームの緊張感を増して、ゲームの興趣性を向上できる。

更に他の構成例として、プロセッサは、所定の開始条件が満たされることによって開始し、所定の終了条件が満たされることで終了するインプレー期間の開始時における移動オブジェクトの移動速度を、直前のインプレー期間終了時における当該移動オブジェクトの移動速度に基づいて決定させてもよい。

上記構成例によれば、上記ラリーが中断され、再開された場合に、移動オブジェクトの移動速度をある程度引き継いで再開できる。これにより、例えば、移動速度を初期速度に戻すことによって、一旦上がった移動速度に慣れたユーザに違和感を与えてしまうようなことを防ぐことができる。

本開示によれば、ユーザキャラクタの役割を多様なものとし、ユーザに様々な役割を担当させることができ、ゲームの興趣性を向上させることができる。
ができる。

ゲーム装置２の内部構成の一例を示すブロック図 役割順番パターンの一例を示す図 役割順番パターンの一例を示す図 本実施形態に係るゲーム画面の一例 図４の仮想ゲーム空間を俯瞰した模式図 クイックスパイクに関して説明するための図 選手キャラクタの移動の一例を示す模式図 選手キャラクタの移動の一例を示す模式図 選手キャラクタの移動の一例を示す模式図 選手キャラクタの移動の一例を示す模式図 選手キャラクタの移動の一例を示す模式図 選手キャラクタの移動の一例を示す模式図 選手キャラクタの移動の一例を示す模式図 選手キャラクタの移動の一例を示す模式図 記憶部２２に記憶される各種データの一例を示すメモリマップ 本実施形態のゲーム処理の詳細を示すフローチャート インプレー処理の詳細を示すフローチャート インプレー処理の詳細を示すフローチャート サーブおよび役割順番設定処理の詳細を示すフローチャート サーブおよび役割順番設定処理の詳細を示すフローチャート オート移動制御処理の詳細を示すフローチャート 手動移動制御処理の詳細を示すフローチャート 役割対応アクション処理の詳細を示すフローチャート ボール移動制御処理の詳細を示すフローチャート 役割変更処理の詳細を示すフローチャート

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

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

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

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

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

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

次に、コントローラ４について説明する。図示は省略するが、本実施形態のコントローラ４は、縦長の形状のハウジングを有しており、縦長となる向きで把持されることが可能である。当該ハウジングは、縦長となる向きで把持される場合に片手で把持可能な形状および大きさをしている。

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

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

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

［本実施形態で想定するゲームについて］
次に、本実施形態にかかるゲーム装置２で実行されるゲーム処理（情報処理の一例）の概要を説明する。まず、本実施形態で想定するゲームは、バレーボールをモチーフにしたゲームである。具体的には、本ゲームでは、仮想的な人型のオブジェクトである、複数の選手キャラクタオブジェクト（以下、単に選手キャラクタと呼ぶ）を、敵チームと味方チームとに分けている。各チームの選手キャラクタは、仮想空間内に用意されたバレーボール用コートにおける、各チームに対応づけられている領域（自側コート、敵側コート）内に配置される。更に、ユーザの操作に基づいて各選手キャラクタに所定のアクションを行わせることで、選手キャラクタと、移動オブジェクトの一例であるボールオブジェクト（以下、単にボールと呼ぶ）とを接触させ、その結果、ボールを移動させることができる。本ゲームは、自側のコートにボールを落とさないようにしながら、３回のボールタッチ（ブロックによるボールタッチは除く）で相手側のコートにボールを返球し合う（ラリーを続ける）ゲームである。また、ボールを相手側コートの領域内に着地させることで、得点として１点が入る。なお、本実施形態では、１ゲームマッチで、先に５点獲得したほうが勝利する場合を例として説明する。

ここで、本ゲームでは、各チームの選手キャラクタは２人であるとする。すなわち、本ゲームは、４人の選手キャラクタによる、２ＶＳ２のチーム対戦形式でプレイするゲームである（いわば、２人制のバレーボールである）。また、本ゲームは、ネットワークを介して複数のユーザでプレイすることが可能である。本実施形態では、１人のユーザが１人の選手キャラクタを担当して操作する場合を想定する。上記のように、本ゲームは２ＶＳ２の形式であるため、最大４人のユーザでオンラインマルチプレイが可能である。また、本実施形態では、１ユーザに１台のゲーム装置が割り当てられ、合計４台のゲーム装置２がネットワーク経由で接続される態様となる。

［ゲーム進行について］
ここで、本ゲームは、各チームの２人の選手キャラクタが、ゲームにおける役割を変えながらプレイするものとなっている。当該役割について説明すると、本ゲームは、バレーボールをモチーフにしたゲームであり、当該役割は、バレーボールにおける役割（ポジション）に該当するものである。具体的は、「サーバー」「レシーバー」「セッター」「スパイカー」「ブロッカー」という５つの役割である。また、上記所定のアクションとは、各役割に応じたアクションである。例えば、役割がセッターである選手キャラクタの場合、ボールをスパイカーにトスするアクション（両手を上に上げてボールをトスするモーション）を上記所定のアクションとして行う。また例えば、役割がスパイカーであれば、（セッターから）トスされたボールを相手コートにスパイクするアクション（ジャンプ、および、腕を振ってボールを打つモーション）を上記所定のアクションとして行う。また例えば、ブロッカーであれば、相手チームのスパイクをブロックするアクション（両手を上に上げてジャンプするようなモーション）を所定のアクションとして行う。本ゲームは、上記のような５つの役割について、チーム内の２人の選手キャラクタの間で、役割を所定の順番で変えながらプレイするゲームとなっている。

上記役割の順番の一例を、図２に示す。また、当該図２を用いて、ゲームの進行の一例を説明する。ここでは、味方チームの選手キャラクタのうち、１人目（１Ｐ側）の選手キャラクタをユーザが操作し、２人目（２Ｐ側）の選手キャラクタを他のユーザが操作する場合を例とする。そして、サーブ権は味方チームにあり、最初にサーバー役を行うのが１人目の選手キャラクタである場合を例とする。試合が開始すると、まず、ユーザの所定の操作に応じて、１人目の選手キャラクタがサーブを行う。当該１人目の選手キャラクタの次の役割は、レシーバーとなる。当該サーブにより、ボールが敵コートにわたり、３回のボールタッチを経てボールが戻ってくることになる。一方、この時点における２人目の選手キャラクタの役割は、ブロッカーとなる。すなわち、敵チームのスパイクをブロックする役割を担当することになる（上記のように、ブロックは、ボールタッチのカウントには含まない）。また、当該２人目の選手キャラクタの次の役割は、セッターとなる。

次に、（上記ブロックで相手のスパイクを止めることが出来ずに）自側コートにボールが戻ってくれば、レシーバー役の１人目の選手キャラクタがボールへの１タッチ目となるアクションを行う。すなわち、ユーザの所定の操作に応じて、１人目の選手キャラクタがボールをレシーブする。当該１人目の選手キャラクタの次の役割は、スパイカーとなる。

続いて、セッター役である２人目の選手キャラクタが、当該ボールへの２タッチ目となるアクションを行う。すなわち、他のユーザの所定の操作に応じて、２人目の選手キャラクタが当該ボールを（スパイカーに）トスするアクションを行う。当該２人目の選手キャラクタの次の役割は、レシーバーとなる。

トスが上がれば、続いて、スパイカー役である１人目の選手キャラクタが当該ボールへの３タッチ目となるアクションを行う。すなわち、ユーザの所定の操作に応じて、１人目の選手キャラクタが当該ボールをスパイクするアクションを行う。スパイクした後、当該１人目の選手キャラクタの次の役割は、ブロッカーとなる。つまり、先ほどは２人目の選手キャラクタが担当していたブロッカーを、今度は１人目の選手キャラクタが担当することになる。

この後は、１人目の選手キャラクタと２人目の選手キャラクタの役割が、上述の説明と入れ替わった順番で割り当てられ、ゲームが進行する。すなわち、１人目の選手キャラクタの役割は、ブロッカー→セッターの順で変化し、２人目の選手キャラクタの役割は、レシーバー→スパイカーの順で変化することになる。

［以下の説明で用いる主な用語について］
以下、上記のようなゲームの流れ（ゲーム処理の概要）について、図面を用いてより具体的に説明するが、これに先立って、以下の説明で用いる主な用語について示す。

まず、ユーザが属するチームのことは「味方チーム」と呼び、他方のチームを「敵チーム」と呼ぶ。

また、上記各選手キャラクタの呼称について、以下の説明では、味方チームのうち、ユーザが操作する選手キャラクタをユーザキャラクタ（以下ではＵＣと略す）と呼び、他方のキャラクタ（他のユーザが操作する選手キャラクタ）を味方キャラクタと呼ぶ。また、敵チームの選手キャラクタについては、敵キャラクタと総称し、個別に示す必要がある場合は、敵キャラクタＡ、敵キャラクタＢと呼ぶ。

また、ボールがコート内に接地する（得点が入る条件が満たされる）ことを、本実施形態では「着地」と呼ぶ。

また、サーブ開始から、ボールが着地する等でラリーが中断するまでの間の期間のことを、「インプレー」と呼ぶ。

また、味方チームがボールタッチ（レシーブ、トス、スパイク）するべき期間のことを、「自側ボール期間」と呼ぶ。具体的には、サーブ権が敵チームにある場合は、敵のサーブが開始されてから敵コートにスパイクするまでの期間となる、また、サーブ権が味方チームにある場合は、敵側のスパイクをレシーブし、スパイクで敵コートに向けてボールを打つまでの期間となる。また、これとは逆に、敵チームがボールタッチすべき期間のことを「敵側ボール期間」と呼ぶ。

また、上記のように、本ゲームでは、各チームで上記役割を所定の順番で入れ替えながら、ゲームが進行する。この所定の順番は、固定的に決定されている順番となっている（より正確には、最初に担当する役割が決まれば、後続の順番が固定的に決まる）。以下の説明では、当該順番のことを「役割順番」と呼ぶ。ここで、当該役割順番は、味方チームの２体の選手キャラクタのうち、いずれが先にサーバー役（味方チームにサーブ権がある場合）、またはレシーバー役（敵チームにサーブ権がある場合）を担当するかによって、役割を割り当てる順番のパターンが２通りあることになる。以下の説明では、１Ｐ側（本例ではユーザ、ＵＣ）が先にサーバーまたはレシーバー役を担当する場合を「順番パターンＡ」と呼び、２Ｐ側（本例では他のユーザ、味方キャラクタ）が先にサーバーまたはレシーバー役を担当する場合を「順番パターンＢ」と呼ぶ。そのため、図２で示した例は「順番パターンＡ」であり、図３に示すような、１Ｐと２Ｐを入れ替えたものが「順番パターンＢ」となる。

また、各役割に応じた上記所定のアクションのことを、以下では総称して「役割対応アクション」と呼ぶ。例えば、サーバーの役割対応アクションは「サーブ」の動作を指し、レシーバーの役割対応アクションは「レシーブ」の動作を指し、セッターの役割対応アクションは「トス」の動作を指し、スパイカーの役割対応アクションは「スパイク」の動作を指し、ブロッカーの役割対応アクションは「ブロック」の動作を指す。

［サーブ権について］
ここで、サーブ権について補足する。本実施形態では、サーブ権の移動に関しては、実際のバレーボールのルールに準ずるものとする。すなわち、サーブ権を持たないチームがラリーを制した場合は、得点とサーブ権を得る。一方、サーブ権を持つチームがラリーを制した場合、サーブ権は移動せず、次のインプレーも、同じチームがサーブを行うものとする。但し、他の実施形態では、いずれのチームがラリーを制したかにかかわらず、一度のインプレー毎にサーブ権が交互に移動するようなゲーム進行としてもよい。

［役割順番の決定タイミングについて］
次に、本実施形態における上記役割順番の決定タイミングに関して説明する。本実施形態では、上記役割順番については、インプレーの中断～再開に際してサーブ権の移動が発生したか否かにかかわらず、インプレー毎に決定される。なお、他の実施形態では、インプレー毎に役割順番を決めることに限らず、例えばサーブ権の移動が発生したときに、役割順番を決め直すような制御を行ってもよい。

ここで、サーブ権が味方チーム側にある場合は、サーブ開始前の時点で、そのときのインプレーにおける味方チーム側の役割順番は決まっている。一方、サーブ権が敵チームにある場合は、サーブ開始前の時点では、ボールがどこに飛んでくるかについては制限がなく、サーブを誰が受けるかについては未定の状態である。そのため、味方チームにおける役割順番が「順番パターンＡ」になるか「順番パターンＢ」になるかが未定の状態である。この場合、役割順番のパターンが決まるタイミングは、敵側のサーブが行われたタイミングとなる。すなわち、敵側のサーブによって移動するボールの移動先（予測着地点）に近い方の選手キャラクタが、レシーバー役として決定される。そして、レシーバー役が決まったタイミングにおいて、上記「順番パターンＡ」になるか、「順番パターンＢ」になるかが確定されることになる。つまり、サーブ権が敵チームにある場合は、敵側のサーブが行われたタイミングで、そのときのインプレーにおける役割順番が決まることになる。

［味方チームにおけるサーバー役の担当順について］
なお、本実施形態では、味方チームにおいてサーバーを担当する順番については、１Ｐ側が先に担当する場合を例として説明する。そのため、サーブ権が味方チーム側にある場合における上記役割順番については、サーバー担当の変化に伴って、「順番パターンＡ」→「順番パターンＢ」の順で繰り返して変化することになる。

［画面例］
次に、図面を用いて、画面例や、選手キャラクタの操作および動作の例について説明する。図４は、本ゲームに係るゲーム画面の一例である。また、図５は、当該ゲーム画面に係る仮想空間を俯瞰したときの各選手キャラクタの位置関係を示す模式図である。図４に示すゲーム画面では、３次元の仮想空間を仮想カメラで撮像した３次元のゲーム画像が表示されている。本ゲームでは、基本的には、仮想カメラは、ＵＣの後方に位置し、３人称視点でＵＣ（の背中）が常に画面内に映るように、その位置や画角が適宜制御される（ＵＣの位置に追従するような制御となる）。この他、ゲームの進行状況や試合展開に応じて、仮想カメラの位置や画角は適宜制御されてもよい。

図４および図５の例では、バレーボールコートはセンターラインを挟んで２つの領域に分けられており、仮想カメラから見て手前側の領域が味方コート、奥行き側の領域が敵コートとなっている。図５の例では、味方コートには、センターライン近傍の位置に味方キャラクタが配置され、エンドライン近傍の位置にＵＣが配置されている。また、敵コートには、センターライン近傍の位置に敵キャラクタＡが、エンドライン近傍の位置に敵キャラクタＢが配置されている。

［選手キャラクタの操作例および動作例］
次に、本実施形態のゲームの流れの概要と選手キャラクタの操作例、動作例等について説明する。

［サーブ権が味方チームにある場合］
まず、味方チームがサーブ権を有する場合のゲームの流れを例示する。上記のように、試合が開始した直後では、最初は１Ｐ側、すなわち、ＵＣがサーバーとなる。そのため、サーブを開始する時点で、今回のインプレーにおける役割順番は、上記「順番パターンＡ」で示す順番になることが確定している。また、この時点では、サーバー役のＵＣはエンドライン近傍の所定の位置、ブロッカー役の味方キャラクタはネットの近傍の所定の位置にいるものとする。

［サーバーについて］
まず、サーバーに関して説明する。サーバーは、ボールを敵コートに向けて打つ役割である。試合が開始すると、ユーザは、ＵＣにサーブさせる操作を行う。本例では、例えば、ユーザは、コントローラ４を把持したまま右腕を上げ（ボールを上げるような操作）、その後タイミング良く振り下ろすような動作（ボールを叩くような操作）を行うことで、サーブ操作を行うことができる。ゲーム装置２は、上記のような振り下ろしの動作を慣性センサー４４に基づいて検出することで、サーブ操作が行われたことを判定することができる。また、本ゲームでは、サーブでボールを移動させる方向（ボールを打ち込む方向）について、腕を振り下ろす方向に応じた左右の打ち分けも可能となっている。このようにユーザがサーブ操作を行えば、ＵＣも、実際のバレーボールにおけるサーブの動作を模した所定のモーション、すなわち、ボールを上げて、右腕（または左腕）でボールを叩くようなモーションを行う。これにより、今回のインプレーが開始することになる。

［敵側ボール期間における操作について］
上記サーブの後、敵チームにおいて、典型的には、レシーブ→トス→スパイクの３タッチ分の動作が行われ、自コートにボールが返ってくる。ここで、ボールが敵チームから返ってくるまでの間、すなわち、上記敵側ボール期間における、ユーザ（ＵＣ）の操作について説明する。敵側ボール期間のうち、予め定義されている一部の期間について、ユーザは、アナログスティック４２を用いて、ＵＣを左右方向（図４，図５のｘ軸方向）に移動させることができる。以下、当該期間のことを手動移動可能期間と呼ぶ。例えば、敵キャラクタがレシーブを行った後からスパイクが行われるまでの期間や、敵キャラクタらがトスをあげた後からスパイクが行われるまでの期間、等である。。手動移動の一例を挙げると、例えば、上記サーブの後は、ＵＣはレシーバーを担当し、味方キャラクタはブロッカーを担当することになる。そのため、サーブ後におけるＵＣの位置は、概ねコートの後方（エンドライン近く）であり、味方キャラクタの位置はネットの近傍となっている。そして、ユーザは、手動移動可能期間において、レシーバーとしてのＵＣをエンドライン近傍で左右に移動させることで、敵スパイカーのスパイク方向をある程度制御することができる（レシーバーがいないほうにスパイク方向を誘導する等）。また、もしＵＣがブロッカー担当のときは、敵がスパイクするまでにネット際で左右方向に移動することで、敵チームのスパイク方向をある程度誘導することも可能である。このようなユーザの手動操作を可能とすることによって、ゲームの戦略性を高め、興趣性をより高めることができる。

なお、ブロッカーについては、手動移動可能期間において、上記の左右方向への移動の他に、ジャンプ操作も可能である、ブロッカーの操作に関しては、後述する。

また、味方キャラクタを操作する他のユーザも、自身の操作するゲーム装置２で同様の操作（この場合はブロッカーとしての操作）が可能である。そして、その操作データがユーザのゲーム装置２に送信され、これに基づき味方キャラクタが動作制御されることになる。

なお、本実施形態では、上記手動移動可能期間における移動方向が左右方向のみの場合を例示した。他の実施形態では、前後方向も含めた全方向（図５のｘｚ平面における３６０度方向）について、手動操作による移動を可能としてもよい。

［自側ボール期間における操作について］
次に、敵チームのスパイクが行われてボールが自コート側に返ってきた後のこと、すなわち、上記自側ボール期間における操作や動作について説明する。まず、当該自側ボール期間においては、ＵＣ（および味方キャラクタ）の「移動」に関しては、自動的な移動制御が行われる（以下、オート移動と呼ぶ）。すなわち、自側ボール期間においては、味方チームの選手キャラクタは、各自の役割に適した位置に向けて自動的に移動するという制御が行われる。以下では、オート移動による移動目標となる位置のことを「移動目標点」と呼ぶ。当該移動目標点は、自コートにおけるボールの予測着地点に基づき、役割毎にそれぞれ算出されるものであり、各役割を担当する選手キャラクタが上記役割対応アクションを実行するに際して適した位置である。例えば、レシーバーの場合は、ボールをレシーブできるような位置である。

ここで、上記ボールの予測着地点および上記移動目標点の算出に関して補足する。本実施形態では、ボールの予測着地点については、ボールと選手キャラクタとの接触、すなわち、サーブ、レシーブ、トス、スパイク、およびブロックが発生したタイミングで、算出・更新され得る。また、移動目標点については、この予測着地点に基づいてその位置が決まる。また、当該移動目標点の算出タイミングに関しては、以下のようなタイミングとなる。まず、サーブ権が味方チーム側にある場合のインプレーでは、味方チームがサーブを行い、これを敵側レシーバーがレシーブしたタイミングで、当該ボールが敵チームのトス、スパイクを経て自側コートに返ってきたことを想定した予測着地点が算出される。具体的には、敵チームによるレシーブが発生したとき、敵チームにおいて、当該レシーブされたボールに対するトスおよび、その後のスパイクが所定の位置で所定のタイミングで行われたと仮定する。そして、この仮定におけるボールの軌道と（敵側スパイクによる）自コートにおけるボールの着地点が予測される。この所定の位置やタイミングとしては、例えば、レシーブから、その後のスパイクによってボールが（相手コート内に）着地するまでにおけるボールの移動が理想的な内容となるような位置やタイミング（以下、総称して理想タイミングと呼ぶ）である。このような仮定で予測された予測着地点に基づいて、一旦、自側のレシーバーの移動目標点（以下、レシーバー目標点と呼ぶこともある）が算出される。更に、自側レシーバーが、このボールを理想タイミングでレシーブしたと仮定して、そのボールの予想着地点も算出し、これに基づき、自側セッターの移動目標点（以下、セッター目標点と呼ぶこともある）も算出される。更に、自側セッターがこのボールを理想タイミングで理想的な位置にトスしたと仮定して、自側スパイカーの移動目標点（後述する通常スパイクポイントおよびクイックポイント）も算出される。つまり、敵チームにおけるレシーブが発生した時点で、所定の条件下（本例では上記理想タイミング）でボールが自コートに返ってくると仮定して、自側のレシーバー、セッター、スパイカーそれぞれの移動目標点を一旦算出している。この後、実際にボールが返ってくるまでの間に敵チーム側で実際に発生したトスおよびスパイクにおけるボールの接触内容に応じて、上記予想着地点および移動目標点は適宜調整される。敵キャラクタとボールとの接触により、ボールの移動方向等が変更される可能性があるためである。なお、当該接触内容とは、例えば、ボールと選手キャラクタとの接触（衝突）角度や接触したときの速度、そのときの選手キャラクタ（の腕）の姿勢や移動方向等のことをいう。そして、敵側のスパイクでボールが返ってくれば、自側ボール期間の間、ＵＣおよび味方キャラクタについて、移動目標点に基づいたオート移動が行われることになる。その後、味方チームでスパイクが行われ、これが敵チームでレシーブされれば、このタイミングで上記のような仮定に基づいた予想着地点および移動目標点の算出が再度行われる。このように、本実施形態では、敵チームにレシーブが発生した時点で一旦、味方チーム側の各役割の移動目標点を算出する。その後、ボールと選手キャラクタとの接触が発生する度に、この移動目標点を適宜調整する、という手法を用いている。なお、敵チーム側も同様の手法で、敵チーム側の移動目標点が算出されている。

なお、他の実施形態では、敵チームのレシーブ発生時ではなく、トスやスパイク、ブロックの発生時に、自コートにおけるボールの予測着地点を算出し、これに基づいてレシーバー等の移動目標点を算出するようにしてもよい。

一方、サーブ権が敵チームにある場合のインプレーでは、敵のサーブ発生時点で、サーブされたボールの予測着地点が算出され、これに基づいて自側レシーバーの移動目標点も算出される。更に、自側レシーバが理想タイミングでレシーブしたと仮定して、自側セッターおよびスパイカーの移動目標点も算出されることになる。

［ブロックの結果について］
ここで、ブロッカーがブロックした場合の結果について説明する。本実施形態では、ブロッカーによるブロックの結果の一例として、次の２つの結果のいずれかになるとする。１つめは「ワンタッチ」と呼ばれるものである。これは、ブロッカーとボールとの接触によって、敵側スパイクに基づいて決定された（自コート側に向かう）ボールの移動軌跡が変更され得るものである。但し、ボールが自コート側に向かう状態に変わりは無く、このボールは自側レシーバーがレシーブする必要がある。そのため、この場合は、ブロック発生に応じて、ボールの予測着地点が修正され、これに応じて自側レシーバーの移動目標点も適宜調整されることになる。

もう１つのブロックの結果は、「跳ね返し」と呼ばれるものである。これは、自コート側に向かうボールの移動を完全に防ぎ、敵コート側にボールを跳ね返す場合である。そのため、この場合は、敵側レシーバーがこのブロックされたボールをレシーブする必要が発生する。この場合は、敵側レシーバーがこのボールをレシーブしたタイミングで、上記のような敵側チームによるその後のトス、スパイクを仮定した味方チームについての移動目標点が算出されることになる。

以下、サーバー以外の役割について、上記自側ボール期間における操作や動作の一例を説明する。

［レシーバーについて］
まず、レシーバーについて説明する。レシーバーは、ボールをレシーブしてセッターに渡す（パスする）役割を有する。換言すれば、ボールを味方コート内において移動させる役割といえる。敵チームからボールが返ってくると、まず、レシーバーによるレシーブが行われることになる。レシーバーは、上記オート移動によって、上記レシーバー目標点に向けて移動する。この位置は、レシーブを行うのに適した位置であり、ボールの予測着地点に基づいて算出される。

レシーバー目標点に向けてのオート移動が開始されるタイミングは、自側ボール期間になったとき、すなわち、敵チームのスパイクが行われたとき（かつ、ブロッカーが完全にブロックできなかった場合）となる。敵チームのスパイクが発生し、ブロッカーがこれを跳ね返すことができなかった場合、レシーバーは、上記のように予め算出されているレシーバー目標点に向けて移動を開始する。なお、（レシーバー担当の）ユーザが、敵側ボール期間の間に、スパイクされる方向をある程度予測して位置取りしていれば、より速やかにレシーバー目標点にレシーバーを移動させることも可能である。そして、レシーバーがレシーバー目標点に到達すれば、当該レシーバーはレシーブの「構え」を取って待機する（つまり、移動せずにボールを待ち受けることになる）。そして、ユーザは、ボールが来たタイミングに合わせてレシーブする操作（以下、レシーブ操作）を行うことで、レシーバーにボールをレシーブさせることができる。なお、このときに、もしユーザがレシーブ操作をしなければ、あるいは、レシーブ操作を行うべきタイミングにユーザの操作が間に合わなかった場合は、ボールはそのまま着地して、インプレーは中断されることになる。この際は、レシーバーとボールの接触判定は行われずに、ボールは着地する（セッター、スパイカー、ブロッカーの場合も同様）。

次に、上記「レシーブ操作」の一例を説明する。本実施形態では、ユーザがコントローラ４を下から上方向に振る動作を、レシーブ操作とする（慣性センサー４４に基づいて、このような動作が検出される）。例えば、ユーザが自身の両腕を、実際にボールをレシーブするときのような姿勢にしてコントローラ４を（所定の姿勢になるようにして）把持し、当該コントローラ４を下から上方向に振るような振り動作を行うことで、レシーブ操作が行われるものとする。なお、レシーブする際のコントローラ４を振る方向やコントローラ４の姿勢に基づき、レシーブしたボールの移動方向を、ある程度調整可能としてもよい。

なお、レシーブ操作に関して、他の実施形態では、上記の操作の他に、所定の操作で「フライングレシーブ」が可能なようにしてもよい。例えば、上記オート移動ではレシーバー目標点に間に合わないような場合に、ユーザが所定のタイミングでコントローラ４を左右に振る動作を行った場合には、レシーバーが「フライングレシーブ」のモーションを行い、これによってレシーブが可能なように構成してもよい。

上記のようなレシーブ操作が適切なタイミングで行われることで。レシーバーにボールをレシーブさせることができる（このレシーブの内容に基づき、セッター目標点も適宜調整され得る）。なお、本ゲームでは、レシーブ操作はしたものの、そのタイミングが合わなかった場合（振り遅れた場合等）は、ボールのレシーブ自体はできるものの、その球速が大きく低下し、ひいては、後続のスパイクの威力が低下する可能性がある。

レシーブをした選手キャラクタは、次に、スパイカーを担当することになるため、レシーブ後、スパイカーについての移動目標点に向けてオート移動を開始することになる。

［セッターについて］
次に、セッターに関して説明する。セッターは、レシーブされたボールを（スパイカーに）トスする役割である。また、セッターも、レシーバー同様に、ボールを味方コート内において移動させる役割といえる。上記セッター目標点は、レシーブされたボールの予測着地点に基づく位置となる。

敵チームのスパイクが発生し、例えばブロッカーであるＵＣがこれを跳ね返すことができなかった場合、自側ボール期間となる。そのため、ブロッカーとしての役割を終えたＵＣは、セッターとして、上記のように予め算出されているセッター目標点に向けてオート移動を開始する。その後、自側レシーブの内容によっては、セッター目標点は適宜修正され得る。なお、後述するが、本実施形態では、レシーブが発生した際、一時的にボールの移動速度を少し低下させる。これにより、セッターがセッター目標点に到達するまでの時間的余裕を作り出している。セッターがセッター目標点に到達すれば、当該セッターはトスの「構え」を取って待機する。なお、他の実施形態では、セッターのオート移動の開始タイミングは、自側のレシーブが発生した時点としてもよい。

次に、セッターの操作例について説明する。本実施形態では、ユーザがコントローラ４を下から上方向に振る動作を、トスする操作（以下、トス操作）とする（慣性センサ－４４に基づいて、このような動作を検出する）。例えば、ユーザが、コントローラを把持したまま自身の両腕を持ち上げ、トスするときのような姿勢を取り、更にコントローラを上方向に押し出すように振ることで、トス操作が行われるものとする。なお、この際、押し出すように振る方向やこのときのコントローラ４の姿勢に基づき、トスを上げる方向をある程度、調整可能としてもよい。

上記のようなトス操作が適切なタイミングで行われることで、ユーザはセッターにボールをトスさせることができる。なお、本ゲームでは、トス操作は行ったものの、そのタイミングが合わなかった場合（振り遅れた場合等）は、トス自体は上げることはできるが、ボールの速度は大きく低下する。その結果、後続のスパイクの威力が低下する可能性もある。

トスをした選手キャラクタは、次に、レシーバーを担当することになる。

［スパイカーについて］
次に、スパイカーに関して説明する。スパイカーは、ボールを敵コート内に向けて打ち込む（移動させる）役割である。レシーバー役の選手キャラクタがレシーブを終えれば、次はスパイカー役として、その移動目標点（トスされたボールを打てる位置）に向けてのオート移動が開始される。

ここで、本ゲームでは、スパイカーは、通常のスパイクの他、いわゆる「クイックスパイク」を打つことが可能となっている。本ゲームでは、クイックスパイクは、トスされたボールが最高点に到達する前のタイミングで打つようなスパイクである。例えば、ボールがネットを少し越える程度の高さまで上がったときにボールを打つようなスパイクである。そのため、スパイカーがボールを打つモーションも、クイックスパイクと通常のスパイクとで少し異なるモーションとなり得る（例えばジャンプする高さ等が異なる）。

本実施形態では、自側のレシーブが行われた際に、上記のようなスパイカーの移動目標点の他に、クイックスパイクが可能な位置も算出される（この他、上記のように敵側レシーブ発生の際にこの位置を算出し、その後調整するようにしてもよい）。以下では、前者を「通常スパイクポイント」と呼び、後者を「クイックポイント」と呼ぶ。図６に、通常スパイクポイントおよびクイックポイントの位置関係の一例を示す。図６では、通常スパイクポイントは、クイックポイントよりもネット寄りの位置で算出されている。トスされたボールは、通常スパイクポイント付近を目指して移動することになる。クイックポイントは、レシーブ直後のスパイカーの位置を始点としてスパイカーが移動開始した場合に、ボールがセッターにトスされる（セッターと接触する）前に到達可能な位置となっている。そして、本実施形態では、スパイクを打つための操作（以下、スパイク操作と呼ぶ）としては同じ操作ではあるが、それを行うタイミングの違いによって、通常のスパイクとクイックスパイクとの２種類のスパイクを使い分けることが可能である。具体例を挙げると、レシーバーとしての役目を終えたＵＣは、スパイカーとして、まず、クイックポイントに向けてオート移動する。クイックポイントに到達すれば、スパイカーは、一旦その場で待機する。そして、このクイックポイントにおいて、セッターがボールをトスする直前となるようなタイミング（クイックスパイク可能なタイミング）でスパイク操作を行うと、スパイカーにクイックスパイクを打たせることが可能である。なお、図６の例では、例えばネット側にダッシュしながらボールを打つようなモーションとなる。一方、クイックスパイク可能なタイミングにおいてこのような操作が行われなかった場合は、スパイカーは通常スパイクポイントに向けてオート移動し、通常スパイクポイントに到達すれば、その場で待機する。そして、ユーザは、ボールが来るタイミングに合わせてスパイク操作を行うことで、通常のスパイクをスパイカーに打たせることができる（例えばその場で真上にジャンプしてボールを打つモーションとなる）。つまり、スパイカーがクイックポイントにいるときに、ユーザがタイミング良くスパイク操作を行えば、スパイカーにクイックスパイクを打たせることができる。また、通常スパイクポイントにスパイカーが到達した後にタイミング良くスパイク操作を行えば、通常のスパイクを打たせることができる。

次に、スパイク操作の例について説明する。本実施形態では、スパイク操作は、「ジャンプ」の操作（以下、スパイクジャンプ操作）と、「インパクト」の操作（以下、インパクト操作）の２段階の操作で構成される。スパイクジャンプ操作は、コントローラ４を下から上に向けて振る、つまり、腕を振り上げる（例えば右腕をバックスイングさせる）ような操作である。また、インパクトの操作は、スパイクジャンプ操作後に、振り上げた腕（コントローラ４）を前→下方向へと振り下ろすような操作である。この２段階の操作を一連の操作として行うものがスパイク操作である。そして、上記のように、通常スパイクポイントでこの一連の操作を行えば、スパイカーに通常のスパイクを打たせることができ、クイックポイントでこの一連の操作を行えば、クイックスパイクを打たせることができる。

なお、本ゲームでは、スパイク操作（特にインパクト操作）したタイミングや、そのときのボールの球速等に基づいて、スパイクの威力（球威）が変化し得る。また、本ゲームでは、当該威力が高い方が、敵側のブロックによって跳ね返されにくくなるような制御も行われる。

スパイカー役の選手キャラクタがスパイク（またはクイックスパイク）を打てば、次に、当該選手キャラクタは、ブロッカーを担当することになる。但し、自身が打ったスパイクがブロックされて、即時に自コートに跳ね返された場合は、ブロッカーの役目が終了したとして、セッターを担当することになる（スパイクによって一旦敵側ボール期間になるが、敵のブロックによって、すぐに自側ボール期間となる）。

［ブロッカーについて］
次に、ブロッカーについて説明する。スパイクした後、スパイカーはブロッカー担当となり、敵チームによるスパイクを防ぐ役割となる。すなわち、ブロッカーは、敵のスパイクを跳ね返して、ボールを敵コートに向けて移動させる役割である。ブロッカーの場合、敵側ボール期間（手動移動可能期間）における操作となるため、オート移動は行われない。ブロッカーの操作は、上記のようなアナログスティック４２による左右方向への移動、および、敵がスパイクするタイミングに合わせて（予測して）ジャンプする、という操作が基本となる。以下、このようなブロッカーのジャンプのことを「ブロックジャンプ」と呼ぶ。

ここで、上述のように、ブロックの結果としては「ワンタッチ」と「跳ね返し」の２つの結果がある。本ゲームでは、ブロックジャンプのタイミングによって、この結果のいずれになるかが決定される。具体的には、ブロックジャンプを開始して、ブロッカーの位置が最高点に到達するまでの間にボールとブロッカーとの接触が検出された場合は、「ワンタッチ」となる。また、ブロックジャンプによってブロッカーが最高点に到達した後、少しの間、ブロッカーが滞空している「滞空期間」が設けられる。この滞空期間中にボールとブロッカーとの接触が検出された場合は、「跳ね返し」という結果になる。

このように、ユーザがブロッカー役として選手キャラクタを操作する場合は、敵チームのスパイクにタイミングを合わせてブロッカーをジャンプさせる、という操作を行うことになる。

［サーブ権が敵チームにある場合］
上記の流れは、味方チームがサーブ権を有する場合の例であった。一方、サーブ権が敵チームにある場合は、敵側のサーブから開始する。この場合、上記のように、敵側のサーブが行われたタイミングで、当該サーブの予想着地点に近い方の選手キャラクタが、レシーバー役として決定される。そして、今回のインプレーにおける役割順番が上記「順番パターンＡ」になるか、「順番パターンＢ」になるかが確定される。また、レシーバー目標点等、味方チーム側の移動目標点も、敵側のサーブ（およびその後のレシーブ）が発生したタイミングで算出される。そのため、サーブ権が敵チームにある場合は、敵チームのサーブが発生したタイミングで、レシーバー、および、セッターのオート移動が開始されることになる。この後は、上記確定した役割順番に基づいて役割を変更しながら、上記と同様の操作・動作が行われる。

［敵サーブから味方チーム得点までの味方チームの動きの一例］
以下、図７～図１４を用いて、敵のサーブから味方チームが得点するまでの一連の流れにおける味方チームの選手キャラクタの移動の一例を示す。これらの図面は、味方コート側を抜き出し、俯瞰して示した模式図である。

まず、図７は、インプレーが開始し、敵のサーブが行われたときの状態を示す。インプレー開始直後では、ＵＣおよび味方キャラクタは、エンドラインの近くに左右に分かれて位置しており、敵サーブの方向に基づき、レシーバーが決まる。ここでは、サーブされたボールが味方コートの左側後方に向けて移動しており、ＵＣがレシーバーに決まった場合を例示する。そして、ＵＣがレシーバーであるため、味方キャラクタはセッターとなり、図７の例では、ネットのある方向に向かってオート移動（太い矢印で示す）を開始する。また、図７の例では、ＵＣについては移動の必要がなかった場合を例示するが、必要に応じて、ＵＣも、ボールの予測着地点に向けてオート移動する。

次に、図８は、ＵＣがレシーブした直後の状態を示す。図８の例では、レシーブの結果、ボールは味方コートの右前方に向けて移動する。そして、そのボールの予測着地点付近には、味方キャラクタが（トスの構えをして）待機している状態である。また、ＵＣは、レシーブが終わり次第、スパイカーとなり、ネットのある方向にオート移動を開始する。なお、ここでは、上記のようなクイックスパイクは行わずに、通常のスパイクが行われる例を示す。

次に、図９は、味方キャラクタがトスを上げた直後の状態を示す。図９では、ボールは左斜め前方に移動し、その予測着地点付近に向けてスパイカーであるＵＣが、オート移動で走ってきていることが示されている。また、トスを上げた味方キャラクタは、次はレシーバーになる。この後、ＵＣは、上記通常スパイクポイントにて、通常のスパイクを打つ。

次に、図１０は、ＵＣがスパイクした直後であり、なおかつ、これが敵ブロッカーにブロック（跳ね返し）された状態を示す。この場合、ブロックされたボールの予測着地点に向けて、レシーバーである味方キャラクタがオート移動する。また、ブロックされたため、スパイクしたＵＣは、次は、セッターとなる（もし、このボールが敵にブロックされていなければ、敵側ボール期間の間、ＵＣはブロッカーとなる）。

次に、図１１は、敵にブロックされたボールが移動している状態を示す。図１１では、味方キャラクタは、オート移動は終えて、ボールの予測着地点付近でレシーブの構えをして待機している状態である。

次に、図１２は、ブロックされたボールを味方キャラクタがレシーブした直後の状態を示す。図１２では、レシーブされたボールの着地予想点に向けてセッターであるＵＣがオート移動している。味方キャラクタは、次にスパイカーとなる。

次に、図１３は、ＵＣがトスを上げた直後の状態を示す。図１３では、トスされたボールは右方向に移動しており、味方キャラクタはネット際（トスされたボールの予測着地点）に向けてオート移動で走ってきている状態である。

最後に、図１４は、味方キャラクタがスパイクした直後の状態を示す。なお、当該スパイクされたボールは、敵にブロックやレシーブされることなく、敵コートに着地したものとする。これにより、味方チームに得点が入ることになる。なお、スパイクされたボールが敵にブロックはされなかったものの、レシーブされた場合は、味方キャラクタはこの後はブロッカーとなる。以上で、図面を用いた移動の例示を終了する。

［ボールの速度調整について］
ところで、本ゲームでは、ゲームバランス調整等の観点から、試合展開等に基づき、ボールの移動速度を適宜調整するという制御も行っている。以下、このようなボールの速度調整に関して説明する。

まず、本ゲームでは、ラリーが続く回数（ボールのコート間の移動回数）が増えるにつれて、ボールの移動速度を徐々に上げていくような調整が行われている。例えば、ラリーの往復が１回分増える毎に、ボールの移動速度を１０％ずつアップさせる、等である（アップする上限を設けてもよい）。更に、本ゲームでは、インプレーが中断し、その後再開した場合、再開したインプレー開始時のボールの移動速度は、前回のインプレーにおける（最終的な）ボールの移動速度に基づいて決定される。具体的には、前回のインプレーの開始時の速度の比率から変動した分の一部（例えば５０％分）を、今回のインプレー開始時におけるボールの移動速度に反映させる。他の実施形態では、上記変動した比率を１００％引き継いでもよい。

また、本ゲームでは、上記のように、レシーブが発生した際、一時的に（セッターがトスするまでの間）、ボールの移動速度を低下させるような制御も行っている。これにより、セッターがセッター目標点に到達するための時間を確保している。

［役割通知機能について］
また、本実施形態では、上記のように役割を割り当てる順番が予めわかっていることから、ユーザが操作するＵＣが、次にどの役割で行動するのかを示すための通知画像を適切なタイミングで表示する制御も行う。本実施形態では、選手キャラクタの役割が上記のような順番で次々に変わっていくため、ユーザが自身の次に役割を把握しきれず、試合途中で混乱してしまう可能性もある。そこで、このような通知を適切なタイミングで表示することで、ユーザが次に何をすべきかを正確に認識させることができる。これにより、ユーザが次に何をすべきかについて戸惑ってしまうことを防ぎ、ゲームを快適にプレイさせることが可能となる。

当該通知の一例を示すと、例えば、ＵＣがレシーブした場合は次の役割はスパイカーとなる。この場合は、ＵＣがレシーブした後、所定時間の間、「次はスパイク」という文字を含む通知画像がゲーム画面上の所定の位置（例えば左上端）に表示されてもよい。また、当該通知画像を表示するタイミングについては、自身の役割を終えた直後に表示開始するようにしてもよいし、役割対応アクションを行うべきタイミングの少し前のタイミングで表示開始するようにしてもよい。例えば、ＵＣがセッター役の場合、次の役割はレシーバーとなる。この場合、表示される通知画像としては、例えば「次はレシーブ」という文字を含む通知画像となる。そして、当該通知画像を表示するタイミングとしては、セッター役のＵＣがトスを行った直後（上記のように、自身の役割を終えた直後）に表示するようにしてもよい。あるいは、ＵＣがトスを行った後、味方のスパイクを経て敵側ボール期間となり、敵チームにおいてトスが発生したタイミングで表示するようにしてもよい。あるいは、当該トスの発生後、敵側のスパイクが発生する少し前のタイミング、換言すれば、次のアクションが敵側のスパイクであることが確定した以降の所定のタイミングに表示するようにしてもよい。但し、この表示タイミングが遅すぎると、事前に通知する意義が薄れるため、遅くとも、役割対応アクションを行うべきタイミングから、例えば１～３秒程度前の時点で通知するようにしてもよい。また、当該通知の表示時間についても、所定時間の間だけ表示して消去してもよいし、そのときの役割を終えるまでの間、常時表示するようにしてもよい。

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

［使用データについて］
まず、本ゲーム処理で利用される各種データに関して説明する。図１５は、ゲーム装置２の記憶部２２に記憶される各種データの一例を示すメモリマップである。記憶部２２には、プログラム記憶領域３０１およびデータ記憶領域３０３が含まれている。プログラム記憶領域３０１には、ゲーム処理プログラム３０２が記憶される。また、データ記憶領域３０３には、ＵＣデータ３０４、味方キャラクタデータ３０５、敵キャラクタデータ３０６、役割順番定義データ３０７、今回順番パターンデータ３０８、ボール移動パラメータ３０９、予測着地点データ３１０、役割毎の移動目標点データ３１１、役割毎のモーションデータ３１２、ゲーム状況管理データ３１３、操作データ３１４、送信用データ３１５、受信データ３１６、自側ボールフラグ３１７等のデータが記憶される。

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

ＵＣデータ３０４は、上記ＵＣに関するデータである。ＵＣデータ３０４には、現在割り当てられている役割を示すデータ（以下、担当役割データ）や、試合中における現在位置を示すデータ、上記対応役割アクションに係るモーションの再生中であるか否かを示すデータ、ＵＣの外観を示すモデルデータや画像データ等が含まれる。

味方キャラクタデータ３０５は、上記味方キャラクタに関するデータである。上記ＵＣデータ３０４と同様のデータが含まれる。また、当該味方キャラクタの操作を担当している他のユーザ、他のゲーム装置２を特定するためのデータ等も含まれる。

敵キャラクタデータ３０６は、上記敵キャラクタに関するデータである。上記味方キャラクタデータ３０５と同内容のデータが含まれている。

役割順番定義データ３０７は、上述した「順番パターンＡ」および「順番パターンＢ」の役割順番を定義したデータである。つまり、上記図２および図３で示した内容をデータとして保存したものである。

今回順番パターンデータ３０８は、現在のインプレーで用いられる役割順番が、上述した「順番パターンＡ」および「順番パターンＢ」のいずれのパターンであるかを指定するデータである。

ボール移動パラメータ３０９は、上記ボールの移動制御に用いる各種パラメータである。例えば、移動方向、移動速度、球威等を示すデータが含まれる。

予測着地点データ３１０は、上記ボールの予測着地点を示すデータである。

役割毎の移動目標点データ３１１は、上記のような移動目標点を、味方チーム／敵チームに分けて、その役割毎に示すデータである。例えば、「味方チームのレシーバ目標点」や「敵チームのセッター目標点」等を示すデータである。また、スパイカーに関しては、上記のように、クイックポイントと通常スパイクポイントの２つがスパイカー用の移動目標点として記憶される。

役割毎のモーションデータ３１２は、選手キャラクタが上記役割対応アクションを行うときに再生するモーションをその役割毎に定義したデータである。

ゲーム状況管理データ３１３は、ゲームの進行を管理するための各種データが記憶される。例えば、サーブ権を有するチーム、各チームの得点、インプレーにおけるラリーの継続回数、等を示すデータが含まれている。

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

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

受信データ３１６は、他のゲーム装置２から受信した上記送信用データ３１５を、他のゲーム装置毎に識別可能なように記憶したデータである。

自側ボールフラグ３１７は、現在が、上記自側ボール期間であるか、敵側ボール期間であるかを示すためのフラグである。当該フラグがオンの場合は自側ボール期間、オフの場合は敵側ボール期間を示すものとする。

その他、記憶部２２には、ゲーム処理で用いられる各種のデータが必要に応じて記憶される。

［プロセッサ２１が実行する処理の詳細］
次に、本実施形態にかかるゲーム処理の詳細を説明する。図１６は、ゲーム処理の詳細を示すフローチャートである。当該ゲーム処理は、例えば、試合開始を指示するユーザの操作に応じて、その実行が開始される。なお、当該処理の実行に先立って、ゲームに参加するユーザのチーム分けは済んでいるものとする。また、当該フローチャートは、処理過程の単なる一例にすぎない。そのため、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判定ステップで利用される閾値も、単なる一例であり、必要に応じて他の値を採用してもよい。

図１６において、まず、ステップＳ１で、プロセッサ２１は、準備処理を実行する。当該処理は、ゲームを開始するための各種の準備を行う処理である。具体的には、プロセッサ２１は、仮想的なバレーコートが存在する仮想ゲーム空間を構築し、味方コート内、敵コート内にそれぞれ、対応するチームの選手キャラクタを配置する。その他、ゲーム処理で用いる各種データの初期化も行う。

次に、ステップＳ２、プロセッサ２１は、インプレー処理を実行する。当該処理は、上記のようなインプレーに係る処理である。図１７および図１８は、当該インプレー処理の詳細を示すフローチャートである。ここで、図１７および図１８のステップＳ１３～Ｓ２４の処理ループについては、１フレーム毎に繰り返されるものとする。図１７において、まず、ステップＳ１１で、プロセッサ２１は、開始演出処理を実行する。例えば、プロセッサ２１は、ゲーム状況管理データ３１３を参照して、現在の得点状況等を判別する、そして、例えば試合開始直後であれば、「試合開始！」等を表示する所定の演出を表示する。また、例えばマッチポイントであれば、そのことを示す所定の演出を表示する。

開始演出の処理が終われば、次に、ステップＳ１２で、プロセッサ２１は、サーブおよび役割順番設定処理を実行する。この処理は、サーブ、および、（今回のインプレーにおける）上記役割順番の順番パターンを決めるための処理である。図１９および図２０は、当該サーブおよび役割順番設定処理の詳細を示すフローチャートである。まず、図１９のステップＳ３１で、プロセッサ２１は、ゲーム状況管理データ３１３を参照して、サーブ権が味方チームにあるか否かを判定する。サーブ権が味方チームにある場合は、ステップＳ３２で、プロセッサ２１は、ゲーム状況管理データ３１３を参照し、ゲームの進行状況に応じて、サーバーを担当する選手キャラクタを決定する。本例では、１Ｐ側の選手キャラクタが先にサーバーを担当する。

次に、ステップＳ３３で、プロセッサ２１は、いずれの選手キャラクタがサーバーを担当するかに基づき、今回のインプレーにおける役割順番を決定する。すなわち、プロセッサ２１は、サーバー役が１Ｐ側の選手キャラクタであれば、今回順番パターンデータ３０８に、「順番パターンＡ」を設定する。一方、サーバー役が２Ｐ側の選手キャラクタであれば、今回順番パターンデータ３０８に、「順番パターンＢ」を設定する。

次に、ステップＳ３４で、プロセッサ２１は、役割順番定義データ３０７および今回順番パターンデータ３０８に基づいて、ＵＣおよび味方キャラクタの上記担当役割データの内容を設定する。すなわち、サーバ、レシーバ、セッター、スパイカー、ブロッカーのうちのいずれかの役割を、上記順番パターンに沿って設定する。

次に、ステップＳ３５で、プロセッサ２１は、仮想空間を仮想カメラで撮像してゲーム画像を生成し、表示部５に表示する。この時点では、サーブ開始前の状態を示すゲーム画面が表示されることになる。

次に、ステップＳ３６で、プロセッサ２１は、操作データ３１４を取得する。更に、プロセッサ２１は、当該操作データ３１４に基づいて送信用データ３１５を生成する。そして、プロセッサ２１は、試合に参加している他のゲーム装置２に当該送信用データ３１５を送信すると共に、他のゲーム装置２から送られてくる送信用データ３１５を受信し、受信データ３１６として格納する。

次に、ステップＳ３７で、プロセッサ２１は、操作データ３１４および受信データ３１６に基づき、味方チームのサーブ操作が行われたか否かを判定する。当該判定の結果、サーブ操作が行われていない場合は（ステップＳ３７でＮＯ）、上記ステップＳ３５に戻り、処理が繰り返される。サーブ操作が行われた場合は（ステップＳ３７でＹＥＳ）、ステップＳ３８で、プロセッサ２１は、コントローラ４の振り方向や振りタイミング等に基づき、選手キャラクタにサーブのモーションを行わせる。そして、プロセッサ２１は、当該サーブに係る選手キャラクタ（の腕の部分）とボールとの接触内容に基づき、ボール移動パラメータ３０９の内容を設定する。ここで、今回のインプレーが、ゲーム開始から２回目以降のインプレーに該当する場合は、プロセッサ２１は、上述したように、ボールの移動速度を、前回のインプレー終了時のボールの移動速度に基づいて決定する。具体的には、前回のインプレーにおいて増加した移動速度の比率の５０％が、今回のサーブ時（インプレー開始時）におけるボールの移動速度に反映されるように、ボール移動パラメータ３０９の内容を設定する。例えば、前回のインプレーにおいて、ボールの移動速度が、標準の速度から５０％アップした状態となっていた場合、今回のインプレー開始時のボールの移動速度が、標準の速度から２５％アップした状態となるように、ボール移動パラメータ３０９の内容を設定する。更に、プロセッサ２１は、上記設定したボール移動パラメータ３０９に基づき、ボールの予測着地点を算出し、予測着地点データ３１０として記憶する。

次に、ステップＳ３９で、プロセッサ２１は、上記予測着地点に基づき、敵チームに係る役割順番を決定する処理を実行する。すなわち、サーブされたボールの予測着地点に基づき敵チーム側のレシーバー役を決定し、これに伴って、敵チーム側の上記順番パターンも決定する。その後、後述するステップＳ４８に処理が進められる。

一方、上記ステップＳ３１の判定の結果、サーブ権が敵チームにある場合は（ステップＳ３１でＮＯ）、ステップＳ４０で、プロセッサ２１は、敵チームに係る役割順番を決定する。

次に、ステップＳ４１で、プロセッサ２１は、仮想空間を仮想カメラで撮像してゲーム画像を生成し、表示部５に表示する。この時点では、敵チームがサーブするのを待っている状態のゲーム画面が表示されることになる。

次に、ステップＳ４２で、プロセッサ２１は、操作データ３１４を取得し、更に、上記送信用データ３１５の他のゲーム装置２への送信、および、他のゲーム装置２からの受信を行う。当該処理は、上記ステップＳ３６と同様の処理であるため、詳細説明は割愛する。

次に、ステップＳ４３で、プロセッサ２１は、敵チームのサーブが行われたか否かを、受信データ３１６に基づいて判定する。当該判定の結果、サーブ操作が行われていない場合は（ステップＳ４３でＮＯ）、上記ステップＳ４１に戻り、処理が繰り返される。敵チームのサーブ操作が行われた場合は（ステップＳ４３でＹＥＳ）、ステップＳ４４で、プロセッサ２１は、上記ステップＳ３８と同様の処理で、ボール移動パラメータ３０９の内容を設定する。更に、プロセッサ２１は、ボールの予測着地点を算出し、予測着地点データ３１０として記憶する。

次に、ステップＳ４５で、プロセッサ２１は、サーブされたボールの予測着地点に基づき、（今回のインプレーにおける最初の）レシーバーを担当する選手キャラクタを決定する。

次に、ステップＳ４６で、プロセッサ２１は、上記決定したレシーバーがいずれの選手キャラクタであるかに基づき、今回のインプレーにおける役割順番を決定する。すなわち、プロセッサ２１は、レシーバーが１Ｐ側の選手キャラクタであれば、今回順番パターンデータ３０８に、「順番パターンＡ」を設定する。一方、レシーバーが２Ｐ側の選手キャラクタであれば、今回順番パターンデータ３０８に、「順番パターンＢ」を設定する。

次に、ステップＳ４７で、プロセッサ２１は、役割順番定義データ３０７および今回順番パターンデータ３０８に基づいて、ＵＣおよび味方キャラクタの上記担当役割データの内容を設定する。

次に、図２０のステップＳ４８で、プロセッサ２１は、上記予測着地点に基づき、味方チーム、敵チームのそれぞれについて、役割毎の移動目標点を算出し、役割毎の移動目標点データ３１１に記憶する。

次に、ステップＳ４９で、プロセッサ２１は、自側ボールフラグ３１７の内容を適宜変更する。すなわち、味方チームのサーブが行われた場合は、自側ボールフラグ３１７にオフを設定する。敵チームのサーブが行われた場合は、自側ボールフラグ３１７をオンに設定する。

次に、ステップＳ５０で、プロセッサ２１は、ボール移動パラメータ３０９に基づいて、ボールを移動させる。

次に、ステップＳ５１で、プロセッサ２１は、ゲーム画像を生成し、表示部５に表示する。この時点では、味方または敵チームがサーブした直後の状態を示すようなゲーム画面が表示されることになる。以上、サーブおよび役割順番設定処理は終了する。

図１７に戻り、次に、ステップＳ１３で、プロセッサ２１は、上記ステップＳ３６と同様の処理で、操作データ３１４を取得し、更に、上記送信用データ３１５の他のゲーム装置２への送信、および、他のゲーム装置２からの受信を行う。

次に、ステップＳ１４で、プロセッサ２１は、オート移動制御処理を実行する。図２１は、当該オート移動制御処理の詳細を示すフローチャートである。図２１において、まず、ステップＳ６１で、プロセッサ２１は、ＵＣが現在、所定の役割対応アクションの動作中（モーションの再生中）の状態であるか否かを判定する。これは例えば、上記ＵＣデータ３０４に含まれる、対応役割アクションに係るモーションの再生中であるか否かを示すデータに基づいて判定できる。当該判定の結果、ＵＣが役割対応アクションの動作中である場合は（ステップＳ６１でＹＥＳ）、後述するステップＳ６４に処理が進められる。一方、ＵＣが役割対応アクションの動作中ではない場合は（ステップＳ６１でＮＯ）、ステップＳ６２で、プロセッサ２１は、上記担当役割データを参照して、ＵＣの現在の役割を判別する。

次に、ステップＳ６３で、プロセッサ２１は、役割毎の移動目標点データ３１１を参照し、各役割に応じた移動目標点に向けて、ＵＣを移動させる。

次に、プロセッサ２１は、味方キャラクタについても上記同様の処理を行う。すなわち、ステップＳ６４で、プロセッサ２１は、味方キャラクタが現在、所定の役割対応アクションの動作中の状態であるか否かを判定する。これは例えば、上記味方キャラクタデータ３０５に含まれる、対応役割アクションに係るモーションの再生中であるか否かを示すデータに基づいて判定できる。当該判定の結果、味方キャラクタが役割対応アクションの動作中である場合は（ステップＳ６４でＹＥＳ）、オート移動制御処理は終了する。一方、役割対応アクションの動作中ではない場合は（ステップＳ６４でＮＯ）、ステップＳ６５で、プロセッサ２１は、上記担当役割データを参照して、味方キャラクタの現在の役割を判別する。

次に、ステップＳ６６で、プロセッサ２１は、役割毎の移動目標点データ３１１を参照し、各役割に応じた移動目標点に向けて、味方キャラクタを移動させる。以上で、オート移動制御処理は終了する。

図１７に戻り、次に、ステップＳ１５で、プロセッサ２１は、現在が上記手動移動可能期間であるか否かを判定する。当該判定の結果、現在が手動移動可能期間でない場合は（ステップＳ１５でＮＯ）、プロセッサ２１は、処理を後述のステップＳ１７に進める。一方、手動移動可能期間である場合は（ステップＳ１５でＹＥＳ）、ステップＳ１６で、プロセッサ２１は、手動移動制御処理を実行する。

図２２は、上記手動移動制御処理の詳細を示すフローチャートである。ステップＳ７１で、プロセッサ２１は、上記操作データ３１４に基づき、ＵＣを移動させる操作（本例ではアナログスティック４２の操作）が行われたか否かを判定する。移動操作が行われていた場合は（ステップＳ７１でＹＥＳ）、ステップＳ７２で、プロセッサ２１は、操作内容に基づいてＵＣを移動させる。一方、移動操作が行われていない場合は（ステップＳ７１でＮＯ）、当該ステップＳ７２の処理はスキップされる。

次に、ステップＳ７３で、プロセッサ２１は、味方キャラクタの移動操作が行われたか否かを受信データ３１６に基づいて判定する。当該判定の結果、移動操作が行われていた場合は（ステップＳ７３でＹＥＳ）、ステップＳ７４で、プロセッサ２１は、操作内容に基づいて味方キャラクタを移動させる。一方、移動操作が行われていない場合は（ステップＳ７３でＮＯ）、当該ステップＳ７４の処理はスキップされる。以上で、手動移動制御処理は終了する。

図１７に戻り、次に、ステップＳ１７で、プロセッサ２１は、敵キャラクタの移動制御処理を実行する。これは、受信データ３１６に基づいて、敵キャラクタについての上記オート移動制御処理、あるいは、（受信データ３１６に基づいた）手動移動制御処理を行う処理である。

次に、ステップＳ１８で、プロセッサ２１は、役割対応アクション制御処理を実行する。この処理では、役割対応アクションを実行させるための操作（上記レシーブ操作等）が行われたか否かを判定し、その結果に基づき各選手キャラクタの役割対応アクションに係る動作を適宜制御するための処理が行われる。図２３は、当該役割対応アクション制御処理の詳細を示すフローチャートである。ここで、図２３のステップＳ８１～Ｓ８５に関しては、説明の便宜上、まず、ＵＣの役割がスパイカー以外である場合について説明し、その後、ＵＣの役割がスパイカーである場合について説明する。

ステップＳ８１において、プロセッサ２１は、ＵＣが現在、役割対応アクションの動作中の状態であるか否かを判定する。当該判定の結果、ＵＣが役割対応アクションの動作中である場合は（ステップＳ８１でＹＥＳ）、後述するステップＳ８２に処理が進められる。一方、ＵＣが役割対応アクションの動作中ではない場合は（ステップＳ８１でＮＯ）、ステップＳ８５で、プロセッサ２１は、操作データ３１４に基づき、そのときのＵＣの役割に応じた役割対応アクションの実行操作が行われたか否かを判定する。具体的には、ＵＣの役割がレシーバーの場合は、上記レシーブ操作が行われたか否かが判定される。ＵＣの役割がセッターの場合は、上記トス操作が行われたか否かが判定される。ＵＣの役割がブロッカーの場合は、上記ブロックジャンプの操作が行われたか否かが判定される（ＵＣの役割がスパイカーの場合については後述する）。

上記判定の結果、そのときのＵＣの役割に対応する役割対応アクションの実行操作が行われた場合は（ステップＳ８５でＹＥＳ）、ステップＳ８６で、プロセッサ２１は、役割毎のモーションデータ３１２の内容に基づき、そのときの役割に対応する役割対応アクションの動作制御が行われる。例えば、レシーバーであれば、レシーブするモーションの再生制御が行われる。具体的には、レシーバーのモーションが開始していなければ、レシーブのモーションを開始させ、モーションの再生中であれば、その再生を（モーションが終了するまで）継続する制御が行われる。また、この際、ＵＣには、ボールとの当たり判定に用いるための当たり判定領域が、その役割に応じた位置に適宜設定される。そして、モーションの変化（例えば腕の位置の変化）に応じて、当該当たり判定領域も移動し得る。その後、後述するステップＳ８７に処理が進められる。

一方、上記ステップＳ８５の判定の結果、そのときのＵＣの役割に対応する役割対応アクションの実行操作が行われていない場合は（ステップＳ８５でＮＯ）、上記ステップＳ８６の処理はスキップされて、後述のステップＳ８７に処理が進められる。

次に、ＵＣの役割がスパイカーの場合について説明する。スパイク操作は、上記のようにスパイクジャンプ操作とインパクト操作との２段階の操作で構成される。そのため、厳密には、スパイクにかかる役割対応アクションとしては、スパイクジャンプのアクションと、インパクトのアクションの２つがある。そのため、この点を考慮して、以下のよう処理の流れとなる。まず、上記ステップＳ８１で、役割対応アクションの動作中か否かが判定されるが、スパイクの場合は、スパイクジャンプおよびインパクトのいずれかの動作中であれば、役割対応アクションの動作中と判定される。当該判定の結果、役割対応アクションの動作中である場合は（ステップＳ８１でＹＥＳ）、ステップＳ８２で、当該役割対応アクションがスパイクジャンプに係るアクションであるか否かが判定される。当該判定の結果、スパイクジャンプのアクション中ではない場合は（ステップＳ８２でＮＯ）、上記ステップＳ８６に進み、現在動作中の役割対応アクションの動作制御が継続される。

一方、上記ステップＳ８２判定の結果、スパイクジャンプのアクション中である場合は（ステップＳ８２でＹＥＳ）、ステップＳ８３で、プロセッサ２１は、操作データ３１４に基づき、インパクト操作が行われたか否かを判定する。当該判定の結果、インパクト操作が行われていれば、ステップＳ８４で、プロセッサ２１は、インパクトに係るモーションを開始させる。その後、上記ステップＳ８６に進むが、これ以降は、当該処理では、インパクトのモーション再生を継続するような動作制御が行われることになる。一方、インパクト操作が行われていない場合は（ステップＳ８３でＮＯ）、上記ステップＳ８６に処理が進められる。この場合は、当該処理では、スパイクジャンプのモーション再生を継続する制御が行われることになる。

次に、ステップＳ８７で、プロセッサ２１は、味方キャラクタについて、役割対応アクションの実行操作の有無判定と、役割対応アクションの動作制御を行う。すなわち、プロセッサ２１は、上記受信データ３１６に含まれる、他のユーザにかかる操作データ３１４を上記操作データ３１４の代わりとして、上述したステップＳ８１～Ｓ８６と同等の処理を行う。

以上で、役割対応アクション制御処理は終了する。

図１７に戻り、次に、ステップＳ１９で、プロセッサ２１は、敵キャラクタについての役割対応アクション制御処理を実行する。この処理は、上記受信データ３１６（に含まれる敵チーム側の操作データ３１４）に基づいて、上記ステップＳ１８の役割対応アクション制御処理と同等の処理を敵キャラクタについて行う処理である。そのため、処理の詳細説明は割愛する。

次に、図１８のステップＳ２０で、プロセッサ２１は、ボール移動制御処理を実行する。図２４は、当該ボール移動制御処理の詳細を示すフローチャートである。まず、ステップＳ９１で、プロセッサ２１は、ボール移動パラメータ３０９に基づいて、ボールを移動させる。

次に、ステップＳ９２で、プロセッサ２１は、いずれかの選手キャラクタとボールとの接触が発生したか否かを判定する。具体的には、レシーブ、トス、スパイク、ブロックのいずれかによる、選手キャラクタとボールとの接触が発生したか否かを判定する（サーブの場合は上記ステップＳ１２の処理にて対応）。

上記判定の結果、選手キャラクタとボールとの接触が発生していない場合は（ステップＳ９２でＮＯ）、後述のステップＳ９６に処理が進められる。一方、接触が発生した場合は（ステップＳ９２でＹＥＳ）、ステップＳ９３で、プロセッサ２１は、当該接触の内容に基づいて、ボール移動パラメータ３０９の内容を算出し、更に、予測着地点データ３１０を算出する。具体的には、プロセッサ２１は、接触発生時におけるコントローラ４の操作内容（振り方向、振る速度等）や接触発生のタイミングに基づいて、ボールの移動方向や移動速度等のパラメータを算出し、ボール移動パラメータ３０９として設定する。例えば、レシーバーまたはセッターとボールとが接触した場合は、レシーバー操作やトス操作に係る操作内容に基づいて、ボール移動パラメータ３０９の内容が算出される。操作内容の一例を挙げると、ベストタイミングとして予め設定されているタイミングと実際に接触が検出されたタイミングとの時間差に基づいて、ボールの移動方向や移動速度等のパラメータが算出されてもよい。

また、スパイカーの場合は、インパクト操作の操作内容に基づき、ボールが敵コート内に向けて移動するようにボール移動パラメータ３０９の内容が算出される。また、ブロッカーとボールが接触した場合は、まず、当該接触のタイミングが上記滞空期間中に発生したか否かに基づき、上記のような「ワンタッチ」に該当するか「跳ね返し」に該当するかが判定される。そして、「ワンタッチ」の場合は、大まかな移動方向自体は味方コート内に向かう方向のまま、若干移動方向を調整したり、あるいは、移動速度のみを低下させるように、ボール移動パラメータ３０９の内容が算出される。また、「跳ね返し」に該当する場合は、ボールの移動方向が敵コート内に向かうように、ボール移動パラメータ３０９の内容が算出される。更に、プロセッサ２１は、上記算出されたボール移動パラメータ３０９に基づいて、ボールの予測着地点を算出し、予測着地点データ３１０として記憶する。

次に、ステップＳ９４で、プロセッサ２１は、上記予測着地点データ３１０に基づき、役割毎に上記移動目標点を算出し、役割毎の移動目標点データ３１１として記憶する。なお、スパイカーに関しては、上記のようにクイックポイントと通常スパイクポイントの２つの移動目標点が算出される。

次に、ステップＳ９５で、プロセッサ２１は、自側ボールフラグ３１７の設定を行う。具体的には、プロセッサ２１は、味方チーム側でスパイクが発生した場合は、自側ボールフラグ３１７にオフを設定する。また、敵チーム側でスパイクが発生した場合は、自側ボールフラグ３１７にオンを設定する。また、「跳ね返し」となるブロックが発生した場合も、上記スパイクと同様の設定が行われる。すなわち、味方チーム側で発生すれば自側ボールフラグ３１７にオフが設定される。敵チーム側で発生した場合は、自側ボールフラグ３１７にオンが設定される。また、これ以外で選手キャラクタとボールとの接触が発生した場合は、自側ボールフラグ３１７の内容は変更しない。

次に、ステップＳ９６で、プロセッサ２１は、ゲーム展開に応じてボールの移動速度を調整する。本実施形態では、レシーブが発生したとき、一時的に（次にトスが発生するまでの間）ボールの移動速度を低下させるよう、ボール移動パラメータ３０９を調整する。また、プロセッサ２１は、上記のように、インプレーにおけるラリーの継続回数に応じて、ボールの移動速度を上げていくような制御も行う。

以上で、ボール移動制御処理は終了する。

図１８に戻り、次に、ステップＳ２１で、プロセッサ２１は、役割変更処理を実行する。図２５は、当該役割変更処理の詳細を示すフローチャートである。まず、ステップＳ１０１で、プロセッサ２１は、自側ボールフラグ３１７に基づき、現在は自側ボール期間であるか否かを判定する。当該判定の結果、自側ボール期間である場合は（ステップＳ１０１でＹＥＳ）、ステップＳ１０２で、プロセッサ２１は、役割を変更するための条件（以下、役割変更条件）が満たされたか否かを判定する。具体的には、味方チーム側において、レシーブ、トス、スパイクが発生した場合、役割変更条件が満たされたと判定される。換言すれば、そのときに割り当てられていた役割を終了したと判定されることになる。

上記判定の結果、役割変更条件が満たされていない場合は（ステップＳ１０２でＮＯ）、後述のステップＳ１０４に処理が進められる。一方、役割変更条件が満たされた場合は（ステップＳ１０２でＹＥＳ）、ステップＳ１０３で、プロセッサ２１は、当該役割変更条件を満たした味方チームの選手キャラクタの役割を、今回順番パターンデータ３０８で示される順番パターンに基づいて変更する。そして、プロセッサ２１は、変更後の役割を上記役割担当データとして記憶する。

一方、上記ステップＳ１０１の判定の結果、現在が敵側ボール期間である場合は（ステップＳ１０１でＮＯ）、ステップＳ１０５で、プロセッサ２１は、ブロッカー担当の選手キャラクタについて、ブロッカーとしての役割を終了したか否かを判定する。具体的には、ブロックによるボールとの接触（跳ね返り、ワンタッチ）の発生の他、ブロックできなかった（ボールと接触できずに抜かれた）場合にも、ブロッカーとしての役割を終了したと判定される。

上記判定の結果、ブロッカーの役割を終了した場合は（ステップＳ１０５でＹＥＳ）、ステップＳ１０６で、プロセッサ２１は、ブロッカー役の選手キャラクタについて、今回順番パターンデータ３０８で示される順番パターンに基づいて役割を変更する。そして、プロセッサ２１は、当該変更後の役割を上記役割担当データとして記憶する。その後、後述のステップＳ１０４に処理が進められる。一方、ブロッカーの役割を終了していない場合は（ステップＳ１０５でＮＯ）、上記ステップＳ１０６の処理はスキップされ（つまり、役割変更は行われず）、後述のステップＳ１０４に処理が進められる。

次に、ステップＳ１０４で、プロセッサ２１は、上述したような、次に役割を通知するための通知画像を適切なタイミングで表示する制御を行う。すなわち、プロセッサ２１は、上記変更後の役割に応じた通知画像を生成する。更に、プロセッサ２１は、当該通知画像がゲーム画面上の所定の位置に、所定のタイミングから所定の期間だけ表示されるように、表示制御を行う。

以上で、役割変更処理は終了する。

図１８に戻り、次に、ステップＳ２２で、プロセッサ２１は、敵チームにおける役割変更処理を実行する。すなわち、プロセッサ２１は、上述したステップＳ２１と同様の処理を敵チームに対しても行う。

次に、ステップＳ２３で、プロセッサ２１は、ボールがコート内に着地したか否かを判定する。まだ着地していない場合は（ステップＳ２３でＮＯ）、ステップＳ２４で、プロセッサ２１は、上記の処理が反映された仮想空間を仮想カメラで撮像することでゲーム画像を生成し、表示部５に出力する。その後、ステップＳ１３に戻り、処理が繰り返される。

一方、ボールがコート内に着地した場合は（ステップＳ２３でＹＥＳ）、インプレーが中断することになる。この場合は、ステップＳ２５で、プロセッサ２１は、得点処理を行う。具体的には、プロセッサ２１は、ボールが着地した位置等に基づいて、味方チームまたは敵チームに得点を与える処理を行う（ゲーム状況管理データ３１３の更新）。以上で、インプレー処理は終了する。

図１６に戻り、次に、ステップＳ３で、プロセッサ２１は、試合終了条件が満たされたか否かをゲーム状況管理データ３１３に基づいて判定する。例えば、いずれかのチームが５点を獲得した場合、試合終了条件が満たされたと判定される。当該判定の結果、試合終了条件が満たされていない場合は（ステップＳ３でＮＯ）、上記ステップＳ２に戻り、処理が繰り返される。一方、試合終了条件が満たされた場合は（ステップＳ３でＹＥＳ）、ステップＳ４で、プロセッサ２１は、試合終了時処理を実行する。例えば、プロセッサ２１は、試合結果や勝敗を示す所定の演出を表示する処理を行う。

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

このように、本実施形態では、１回分のインプレーの期間において、選手キャラクタの役割を所定の順番で順次割り当てる制御を行っている。これにより、インプレー中においてユーザ（選手キャラクタ）が行う役割を多様なものとすることができ、球技ゲームの興趣性を向上させることができる。

［変形例］
なお、上記実施形態では、敵側ボール期間の一部の期間（手動移動可能期間）において、手動で移動可能な例をあげた。そして、上記の例ではオート移動制御処理の終了後に手動移動可能期間か否かの判定を行うような処理例をあげた。この他、他の実施形態では、オート移動制御処理と手動移動制御処理とを並列的に処理してもよい。例えば、オート移動の制御中であっても、アナログスティック４２の入力操作が検出された場合は、（オート移動制御を中断して）当該入力操作に基づく手動移動制御処理を優先的に実行するようにしてもよい。

また、上記ブロッカー、レシーバーの移動目標点については、以下のような制御を行ってもよい。例えば、敵側のスパイカーの位置に応じて、ブロッカーの上記移動目標点を決定し、そこに向けてブロッカーがオート移動するように制御してもよい。また、味方側のレシーバーについても、ブロッカーと同じく、敵側のスパイカーの位置に応じて移動目標点を決定し、オート移動するようにしてもよい。また、レシーバーについては、味方側のブロッカーの位置に応じて移動目標点を決定するようにしてもよい。更には、レシーバーについては、敵側スパイカーの位置、および、味方側のブロッカーの位置の双方を考慮して、移動目標点を決めるようにしてもよい。

また、上記実施形態では、ゲーム展開に応じてボールの移動速度を調整していた。この他、得点が少ない方のチーム（劣勢にあるチーム）については、（その得点差等に応じて）選手キャラクタの移動速度を高めるような調整を行ってもよい。これにより、劣勢なチームについては、選手キャラクタの移動速度が上がるため、ボールが拾いやすくなる。すなわち、劣勢のチームについて、ボールがコートに着地しにくくすることができる。これにより、一方的なゲーム展開となってゲームの興趣性が低下する可能性を軽減できる。

また、上記実施形態では、敵チームにサーブ権がある場合は、敵側のサーブが発生したときに、そのサーブ方向に応じてレシーバーを決め、これに伴って味方チームの役割順番を決めていた。他の実施形態では、これに限らず、敵チームにサーブ権がある場合でも、敵側サーブが行われる前の段階で味方チームの役割順番を決めるようにしてもよい。例えば、前回のインプレーでは順番パターンＡを用いていた場合は、今回のインプレーに際しては無条件に順番パターンＢのほうを用いる、等である。

また、ゲームに参加するユーザの人数について、上記の例では４人のユーザが参加する例を挙げたが、これに限らず、一部の選手キャラクタをプロセッサ２１によるＡＩ制御としてもよい。例えば、ユーザは１人だけであり、味方キャラクタ、敵キャラクタについてはプロセッサ２１によるＡＩ制御としてもよい。

また、上記実施形態では、バレーボールゲームを一例として説明した。バレーボールの他、チーム対戦する球技であって、ボールのラリーを続けるような球技ゲームについても、上記実施形態の処理は適用可能である。また、その他、複数の役割がある球技ゲームについても、上記実施形態の処理は適用可能である。例えば、サッカーをモチーフにした球技ゲームにおいて、ＦＷ役とＭＦ役とＤＦ役（更にはＧＫ役）を、ゲーム進行中に複数のユーザ間で、所定のタイミングに所定の順番で変化させていくような球技ゲームを実行してもよい。

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

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

Claims (19)

1. 操作装置と、プロセッサを備える情報処理装置とを含む情報処理システムであって、
   前記操作装置は、少なくとも、
   方向入力部と、
   慣性センサーと、
   前記慣性センサーの出力、および前記方向入力部の出力に基づく操作データを前記情報処理装置に送信するデータ送信部とを備え、
   前記プロセッサは、少なくとも、
   仮想空間内の移動オブジェクトと、ユーザの操作対象であるユーザキャラクタと、味方キャラクタと、敵キャラクタとを含むキャラクタオブジェクトを用いたスポーツに関するゲームを実行し、
   前記ユーザキャラクタと前記味方キャラクタとを前記仮想空間の第１領域に配置し、前記敵キャラクタを当該仮想空間の第２領域に配置し、
   前記ユーザキャラクタを視野に含む位置であって、当該ユーザキャラクタの後方となる位置に仮想カメラを配置し、
   前記ユーザキャラクタの移動に追従するように当該仮想カメラの位置を制御し、
   前記ユーザキャラクタに、前記移動オブジェクトを前記第１領域において移動させる役割、または、前記移動オブジェクトを前記第２領域に向けて移動させる役割を少なくとも含む複数の役割のうち、１つの役割をゲームの進行に応じて所定の順番で割り当て、
   所定の役割が割り当てられている前記ユーザキャラクタを、
   当該所定の役割と、前記移動オブジェクトの移動方向とに基づいて、前記第１領域内において自動的に移動、または、
   当該所定の役割と前記方向入力部の出力とに基づいて、前記仮想カメラの位置から見て少なくとも左右方向に移動させ、
   前記ユーザキャラクタに前記所定の役割が割り当てられている場合であって、前記データ送信部から取得した前記操作データが当該所定の役割に対応した条件を満たす場合、当該所定の役割と当該操作データとに基づく当該ユーザキャラクタのアクションによって前記移動オブジェクトを移動させる、情報処理システム。
2. 前記方向入力部の出力に基づく移動は、前記移動オブジェクトが前記第２領域内にあるときに可能である、請求項１に記載の情報処理システム。
3. 前記複数の役割のうち１つの役割は、前記移動オブジェクトとの位置関係に関わらず、前記ユーザキャラクタに割り当てられる、請求項１～２のいずれかに記載の情報処理システム。
4. 前記ユーザキャラクタに関する前記所定の順番は、前記移動オブジェクトを前記第１領域に向けて移動させる役割が割り当てられた前記敵キャラクタが当該役割に基づく所定のアクションを行ったときに決定される、請求項１～３のいずれかに記載の情報処理システム。
5. 前記プロセッサは、更に、前記敵キャラクタの位置に少なくとも基づいて、前記ユーザキャラクタを自動的に移動させる、請求項１～４のいずれかに記載の情報処理システム。
6. 前記プロセッサは、更に、前記味方キャラクタの位置に少なくとも基づいて、前記ユーザキャラクタを自動的に移動させる、請求項１～５のいずれかに記載の情報処理システム。
7. 前記プロセッサは、前記ユーザキャラクタに第１役割が割り当てられている場合、前記第１領域に向かって移動する前記移動オブジェクトと当該ユーザキャラクタとの位置関係が所定の条件を満たす場合、当該移動オブジェクトの移動方向を前記第２領域に向かう方向に変更させる、請求項１～６のいずれかに記載の情報処理システム。
8. 前記プロセッサは、前記ユーザキャラクタに第２役割が割り当てられている場合であって、前記操作装置が第１タイミングにおいて所定の姿勢で振られたことを前記操作データが示す場合、当該操作データに基づいて前記移動オブジェクトを前記第２領域へ向けて移動させる、請求項１～７のいずれかに記載の情報処理システム。
9. 前記プロセッサは、前記ユーザキャラクタに前記第２役割が割り当てられている場合であって、前記操作装置が前記第１タイミングよりも速い第２タイミングにおいて所定の姿勢で振られたことを前記操作データが示す場合、当該操作データに基づいて前記移動オブジェクトを前記第２領域へ向けて移動させる、請求項８に記載の情報処理システム。
10. 前記情報処理システムは、第２情報処理装置を更に含み、
    前記敵キャラクタ、または、前記味方キャラクタは、前記第２情報処理装置のユーザの操作対象として設定され、
    前記プロセッサは、前記移動オブジェクトを前記第１領域において移動させる役割、または、前記移動オブジェクトを前記第２領域に向けて移動させる役割を少なくとも含む複数の役割のうち、１つの役割をゲームの進行に応じて所定の順番で前記ユーザキャラクタに割り当てる、請求項１～９のいずれかに記載の情報処理システム。
11. 前記プロセッサは、更に、前記ユーザキャラクタに割り当てられた役割をユーザに示す通知画像を表示する、請求項１～１０のいずれかに記載の情報処理システム。
12. 前記プロセッサは、ユーザキャラクタに割り当てられる役割が変更されたときに、前記通知画像を表示する、請求項１１に記載の情報処理システム。
13. 前記プロセッサは、前記所定の役割がユーザキャラクタに割り当てられた後、当該役割に対応する操作を行うべきタイミングよりも前のタイミングで前記通知画像を表示する、請求項１１に記載の情報処理システム。
14. 前記プロセッサは、前記ユーザキャラクタおよび味方キャラクタが属する味方チームと、前記敵キャラクタが属する敵チームとで、不利なゲーム展開となっているチームに属するキャラクタオブジェクトの移動速度を増加させる、請求項１～１３のいずれかに記載の情報処理システム。
15. 前記プロセッサは、前記第１領域および前記第２領域間における前記移動オブジェクトの移動回数の増加に応じて、当該移動オブジェクトの移動速度を増加させる、請求項１～１４のいずれかに記載の情報処理システム。
16. 前記プロセッサは、所定の開始条件が満たされることによって開始し、所定の終了条件が満たされることで終了するインプレー期間の開始時における前記移動オブジェクトの移動速度を、直前のインプレー期間終了時における当該移動オブジェクトの移動速度に基づいて決定する、請求項１５に記載の情報処理システム。
17. 操作装置と、情報処理システムのコンピュータに実行させる情報処理プログラムであって、
    前記操作装置には、少なくとも、
    方向入力部と、
    慣性センサーと、
    前記慣性センサーの出力、および前記方向入力部の出力に基づく操作データを前記情報処理システムに送信するデータ送信部とが備えられ、
    前記コンピュータに、
    仮想空間内の移動オブジェクトと、ユーザの操作対象であるユーザキャラクタと、味方キャラクタと、敵キャラクタとを含むキャラクタオブジェクトを用いたスポーツに関するゲームを実行させ、
    前記ユーザキャラクタと前記味方キャラクタとを前記仮想空間の第１領域に配置させ、前記敵キャラクタを当該仮想空間の第２領域に配置させ、
    前記ユーザキャラクタを視野に含む位置であって、当該ユーザキャラクタの後方となる位置に仮想カメラを配置させ、
    前記ユーザキャラクタの移動に追従するように当該仮想カメラの位置を制御させ、
    前記ユーザキャラクタに、前記移動オブジェクトを前記第１領域において移動させる役割、または、前記移動オブジェクトを前記第２領域に向けて移動させる役割を少なくとも含む複数の役割のうち、１つの役割をゲームの進行に応じて所定の順番で割り当てさせ、
    所定の役割が割り当てられている前記ユーザキャラクタを、当該所定の役割と、前記移動オブジェクトの移動方向とに基づいて、前記第１領域内において自動的に移動、または、
    当該所定の役割と前記方向入力部の出力とに基づいて、前記仮想カメラの位置から見て少なくとも左右方向に移動させ、
    前記ユーザキャラクタに前記所定の役割が割り当てられている場合であって、前記データ送信部から取得した前記操作データが当該所定の役割に対応した条件を満たす場合、当該所定の役割と当該操作データとに基づく当該ユーザキャラクタのアクションによって前記移動オブジェクトを移動させる、情報処理プログラム。
18. 操作装置と、プロセッサを備える情報処理装置であって、
    前記操作装置は、少なくとも、
    慣性センサーと、
    方向入力部と、
    前記慣性センサーの出力、および前記方向入力部の出力に基づく操作データを前記情報処理装置に送信するデータ送信部とを備え、
    前記プロセッサは、少なくとも、
    仮想空間内の移動オブジェクトと、ユーザの操作対象であるユーザキャラクタと、味方キャラクタと、敵キャラクタとを含むキャラクタオブジェクトを用いたスポーツに関するゲームを実行し、
    前記ユーザキャラクタと前記味方キャラクタとを前記仮想空間の第１領域に配置し、前記敵キャラクタを当該仮想空間の第２領域に配置し、
    前記ユーザキャラクタを視野に含む位置であって、当該ユーザキャラクタの後方となる位置に仮想カメラを配置し、
    前記ユーザキャラクタの移動に追従するように当該仮想カメラの位置を制御し、
    
    前記ユーザキャラクタに、前記移動オブジェクトを前記第１領域において移動させる役割、または、前記移動オブジェクトを前記第２領域に向けて移動させる役割を少なくとも含む複数の役割のうち、１つの役割をゲームの進行に応じて所定の順番で割り当て、
    所定の役割が割り当てられている前記ユーザキャラクタを、当該所定の役割と、前記移動オブジェクトの移動方向とに基づいて、前記第１領域内において自動的に移動、または、
    当該所定の役割と前記方向入力部の出力とに基づいて、前記仮想カメラの位置から見て少なくとも左右方向に移動させ、
    前記ユーザキャラクタに前記所定の役割が割り当てられている場合であって、前記データ送信部から取得した前記操作データが当該所定の役割に対応した条件を満たす場合、当該所定の役割と当該操作データとに基づく当該ユーザキャラクタのアクションによって前記移動オブジェクトを移動させる、情報処理装置。
19. 操作装置を備える情報処理システムのプロセッサに実行させる情報処理方法であって、
    前記操作装置には、少なくとも、
    慣性センサーと、
    方向入力部と、
    前記慣性センサーの出力、および前記方向入力部の出力に基づく操作データを前記情報処理システムに送信するデータ送信部とが備えられ、
    前記プロセッサに、
    仮想空間内の移動オブジェクトと、ユーザの操作対象であるユーザキャラクタと、味方キャラクタと、敵キャラクタとを含むキャラクタオブジェクトを用いたスポーツに関するゲームを実行させ、
    前記ユーザキャラクタと前記味方キャラクタとを前記仮想空間の第１領域に配置し、前記敵キャラクタを当該仮想空間の第２領域に配置させ、
    前記ユーザキャラクタを視野に含む位置であって、当該ユーザキャラクタの後方となる位置に仮想カメラを配置させ、
    前記ユーザキャラクタの移動に追従するように当該仮想カメラの位置を制御させ、
    前記ユーザキャラクタに、前記移動オブジェクトを前記第１領域において移動させる役割、または、前記移動オブジェクトを前記第２領域に向けて移動させる役割を少なくとも含む複数の役割のうち、１つの役割をゲームの進行に応じて所定の順番で割り当てさせ、
    所定の役割が割り当てられている前記ユーザキャラクタを、当該所定の役割と、前記移動オブジェクトの移動方向とに基づいて、前記第１領域内において自動的に移動、または、
    当該所定の役割と前記方向入力部の出力とに基づいて、前記仮想カメラの位置から見て少なくとも左右方向に移動させ、
    前記ユーザキャラクタに前記所定の役割が割り当てられている場合であって、前記データ送信部から取得した前記操作データが当該所定の役割に対応した条件を満たす場合、当該所定の役割と当該操作データとに基づく当該ユーザキャラクタのアクションによって前記移動オブジェクトを移動させる、情報処理方法。

Images