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

Abstract

【課題】ゲームの状況に応じて、より自然で違和感の少ない音声表現が可能な情報処理プログラム、情報処理装置、情報処理システム、および情報処理方法を提供すること。
【解決手段】少なくとも１つのオブジェクトにより構成されるオブジェクトグループについて、オブジェクトの総数に応じて再生するサウンド数を決定する。また、オブジェクトグループを構成するオブジェクトの種類毎の数の比率に基づく確率で、当該オブジェクトの種類毎に関連付けられた再生用サウンドが抽選されるように当該再生用サウンドを上記サウンド数だけ抽選し、再生する。
【選択図】図３４

Description

本開示は、ゲーム内におけるオブジェクトのグループに係る音声データの再生制御に関する。

従来から、ガヤ音声の再生が可能な音声再生プログラムが知られている（例えば特許文献１）。当該音声再生プログラムでは、仮想空間において動作する複数の動的オブジェクトの全部または一部を複数のクラスタに分け、各クラスタに対して対応づけられた音声を再生している。

特開２０２１－７４３９６号公報

上記の技術では、各クラスタに対応する音声について、次のように決定している。まず、各クラスタについて、男性キャラクタと女性キャラクタの数を確認する。次に、所定の音源データの中から、男性の音声として用意された音源データを男性の人数分だけ選択する。更に、当該音源データの中から、女性の音声として用意された音源データを女性の人数分だけ選択する。そして、選択された音源データを各クラスタの代表点（クラスタの重心）の位置で再生している。

しかしながら、上記の手法で選択された音声を再生した場合、あるクラスタからは、常に、そのクラスタの男女の人数に応じた音声が再生されることになる。つまり、再生される音声における男女の声の数の比率が常に一定であるため、機械的な音声再生がなされているという印象をユーザに与える側面があった。そのため、より自然な音声表現を行うという観点で改良の余地があった。

それ故に、本開示における目的は、ゲームの状況に応じて、より自然で違和感の少ない音声表現が可能な情報処理プログラム、情報処理装置、情報処理システム、および情報処理方法を提供することである。

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

（構成１）
構成１は、情報処理装置のコンピュータにおいて実行される情報処理プログラムであって、コンピュータに、グループ管理処理と、サウンド取得処理と、構成オブジェクト取得処理と、サウンド数決定処理と、サウンド抽選処理と、再生処理とを行わせる。グループ管理処理では、仮想空間に配置された少なくとも１つのオブジェクトにより構成されるオブジェクトグループを管理させる。サウンド取得処理では、オブジェクトの種類毎に少なくとも１つが関連付けられた再生用サウンドを取得させる。構成オブジェクト取得処理では、オブジェクトグループを構成するオブジェクトの種類毎の数の情報を取得させる。サウンド数決定処理では、オブジェクトグループを構成するオブジェクトの総数である構成オブジェクト数に応じて、再生するサウンド数を決定させる。サウンド抽選処理では、オブジェクトグループを構成するオブジェクトの種類毎の数の比率に基づく確率で、当該オブジェクトの種類毎に関連付けられた再生用サウンドが抽選されるように、当該再生用サウンドを上記サウンド数だけ抽選させる。再生処理では、サウンド抽選処理により抽選された再生用サウンドを再生させる。そして、構成オブジェクト取得処理、サウンド数決定処理、サウンド抽選処理、および再生処理を継続的に繰り返し行わせる。

上記構成によれば、オブジェクトグループの総数に応じて再生サウンド数を決定しつつ、オブジェクトの種類毎の数の比率に基づく確立で再生用サウンドを抽選する。これにより、グループを構成するオブジェクトの総数が増えれば再生サウンド数を増やすことができる。また、当該オブジェクトの種類の比率に基づいて再生用サウンドが抽選される。そのため、短期的に見ると、再生されるサウンドの種類にランダム性をもたせることができる。また、長期的に見た場合、再生されるサウンドの種類の比率は、オブジェクトグループを構成するオブジェクトの種類の比率に収束していくことになる。これにより、グループを目視せずとも、そのグループを構成しているオブジェクトの数や種類をユーザに認識させることができる。

（構成２）
構成２は、上記構成１において、コンピュータに、サウンド数決定処理として、構成オブジェクト数に応じた確率に基づいて、サウンド数を決定させてもよい。

上記構成によれば、所定のタイミングで再生されるサウンド数について、ランダム性を持たせることができる。これにより、更に自然な音声表現が可能となる。

（構成３）
構成３は、上記構成１または２において、サウンド数決定処理として、コンピュータに、構成オブジェクト数が増えるほどサウンド数の増加分が逓減するようにして当該サウンド数を決定させてもよい。

上記構成によれば、グループを構成するオブジェクト数が少ない場合、サウンド数が増加したことをユーザが認識しやすくなる。

（構成４）
構成４は、上記構成１～３のいずれかにおいて、コンピュータに、オブジェクトの種類毎に少なくとも２つが関連付けられた再生用サウンドを取得するサウンド取得処理を行わせてもよい。更に、オブジェクトの種類ごとに関連付けられた少なくとも２つの再生用サウンドの中から１つを選択するようにサウンド抽選処理を行わせてもよい。

上記構成によれば、同じ種類のオブジェクトから、複数種類の音声が発せられる。そのため、同じオブジェクトからは同じ音声ばかり再生される場合に比べ、機械的な再生という印象を与えることを防ぎ、より自然な音声表現が可能となる。

（構成５）
構成５は、上記構成１～４のいずれかにおいて、再生処理として、コンピュータに、サウンド抽選処理において同じ再生用サウンドが複数回抽選された場合、当該再生用サウンドを重ねて、または、当該再生用サウンドの音量が大きくなるように再生させてもよい。

上記構成によれば、複数の同じ音声が同時に再生される場合、その音声に係る再生音量を大きくすることができる。これにより、同じ音声が重なって聞こえた結果、大きな音量で聞こえてくるという、違和感のない自然な音声表現ができる。

（構成６）
構成６は、上記構成１～５のいずれかにおいて、再生処理として、コンピュータに、構成オブジェクト数が多いほど再生用サウンドの再生速度が速くなるように再生させてもよい。

上記構成によれば、グループの構成オブジェクト数の大小に応じて再生速度も変わるため、ユーザは、再生用サウンドを聞くだけで、グループの構成オブジェクト数の大小をある程度把握することができる。

（構成７）
構成７は、上記構成１～６において、再生処理として、コンピュータに、オブジェクトグループ毎に決定される、当該オブジェクトグループの構成オブジェクト数よりも小さな数であって１以上の数のサウンド再生位置から再生用サウンドを再生させてもよい。

上記構成によれば、処理負荷を抑えながら、再生位置について違和感のない再生用サウンドの再生ができる。

（構成８）
構成８は、上記構成１～７において、仮想空間には複数個のオブジェクトグループが存在してもよい。そして、コンピュータに、複数個のオブジェクトグループ毎に、構成オブジェクト取得処理、サウンド数決定処理、サウンド抽選処理、および再生処理を継続的に繰り返し行わせてもよい。

上記構成によれば、グループ毎に異なった音声表現が実現できる。

（構成９）
構成９は、上記構成１～８のいずれかにおいて、再生処理として、コンピュータに、ランダムで決定された音量で再生用サウンドを再生させてもよい。

上記構成によれば、オブジェクト毎に音量が異なっている（声の大きさが異なっている）様子を表現できるため、より自然な音声表現が可能となる。

（構成１０）
構成１０は、上記構成１～９のいずれかにおいて、コンピュータに更に、ユーザの操作入力に応じて、仮想空間にオブジェクトを配置させてもよい。

上記構成によれば、そのときのゲームの状況に応じた、違和感のない自然な音声表現ができる。

（構成１１）
構成１１は、上記構成１～１０のいずれかにおいて、コンピュータに更に、仮想空間に配置されたアイテムに対してオブジェクトに共同作業を行わせ、オブジェクトが当該共同作業を行っているときに、再生用サウンドを再生する再生処理を行わせてもよい。

上記構成によれば、共同作業中における「かけ声」のような音声表現について、より自然な音声表現が可能となる。

本実施形態によれば、より自然な感じの音声表現ができる。また、ユーザに音声を聞かせるだけで、オブジェクトグループの大まかな構成を把握させることもできる。

本体装置２に左コントローラ３および右コントローラ４を装着した状態の一例を示す図 本体装置２から左コントローラ３および右コントローラ４をそれぞれ外した状態の一例を示す図 本体装置２の一例を示す六面図 左コントローラ３の一例を示す六面図 右コントローラ４の一例を示す六面図 本体装置２の内部構成の一例を示すブロック図 本体装置２と左コントローラ３および右コントローラ４との内部構成の一例を示すブロック図 本実施形態に係るゲーム画面の一例 本実施形態に係るゲーム画面の一例 本実施形態に係るゲーム画面の一例 本実施形態に係るゲーム画面の一例 本実施形態に係るゲーム画面の一例 本実施形態に係るゲーム画面の一例 本実施形態に係るゲーム画面の一例 本実施形態に係るゲーム画面の一例 第１キャラクタの総数と同時再生数の相関関係の一例 運搬ボイスの再生例 それぞれ異なる第１キャラクタの構成比率の再生例 それぞれ異なる第１キャラクタの構成比率の再生例 それぞれ異なる第１キャラクタの構成比率の再生例 ＤＲＡＭ８５に記憶される各種データの一例を示すメモリマップ ＰＣデータ３０２の一例 第１キャラクタデータ３０３の一例 運搬ボイスデータ３０４の一例 種類ボイス定義データ３０５の一例 運搬物データ３０６の一例 操作データ３０７の一例 グループ基本データ３０９の一例 構成メンバーデータ３１０の一例 再生ボイス指定データ３１１の一例 本実施形態に係るゲーム処理の詳細を示すフローチャート 運搬グループ管理処理の詳細を示すフローチャート 運搬グループ動作制御処理の詳細を示すフローチャート 再生ボイス決定処理の詳細を示すフローチャート

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

以下、本実施形態の一例に係るゲームシステムについて説明する。本実施形態におけるゲームシステム１の一例は、本体装置（情報処理装置；本実施形態ではゲーム装置本体として機能する）２と左コントローラ３および右コントローラ４とを含む。本体装置２は、左コントローラ３および右コントローラ４がそれぞれ着脱可能である。つまり、ゲームシステム１は、左コントローラ３および右コントローラ４をそれぞれ本体装置２に装着して一体化された装置として利用できる。また、ゲームシステム１は、本体装置２と左コントローラ３および右コントローラ４とを別体として利用することもできる（図２参照）。以下では、本実施形態のゲームシステム１のハードウェア構成について説明し、その後に本実施形態のゲームシステム１の制御について説明する。

図１は、本体装置２に左コントローラ３および右コントローラ４を装着した状態の一例を示す図である。図１に示すように、左コントローラ３および右コントローラ４は、それぞれ本体装置２に装着されて一体化されている。本体装置２は、ゲームシステム１における各種の処理（例えば、ゲーム処理）を実行する装置である。本体装置２は、ディスプレイ１２を備える。左コントローラ３および右コントローラ４は、ユーザが入力を行うための操作部を備える装置である。

図２は、本体装置２から左コントローラ３および右コントローラ４をそれぞれ外した状態の一例を示す図である。図１および図２に示すように、左コントローラ３および右コントローラ４は、本体装置２に着脱可能である。なお、以下において、左コントローラ３および右コントローラ４の総称として「コントローラ」と記載することがある。

図３は、本体装置２の一例を示す六面図である。図３に示すように、本体装置２は、略板状のハウジング１１を備える。本実施形態において、ハウジング１１の主面（換言すれば、表側の面、すなわち、ディスプレイ１２が設けられる面）は、大略的には矩形形状である。

なお、ハウジング１１の形状および大きさは、任意である。一例として、ハウジング１１は、携帯可能な大きさであってよい。また、本体装置２単体または本体装置２に左コントローラ３および右コントローラ４が装着された一体型装置は、携帯型装置となってもよい。また、本体装置２または一体型装置が手持ち型の装置となってもよい。また、本体装置２または一体型装置が可搬型装置となってもよい。

図３に示すように、本体装置２は、ハウジング１１の主面に設けられるディスプレイ１２を備える。ディスプレイ１２は、本体装置２が生成した画像を表示する。本実施形態においては、ディスプレイ１２は、液晶表示装置（ＬＣＤ）とする。ただし、ディスプレイ１２は任意の種類の表示装置であってよい。

また、本体装置２は、ディスプレイ１２の画面上にタッチパネル１３を備える。本実施形態においては、タッチパネル１３は、マルチタッチ入力が可能な方式（例えば、静電容量方式）のものである。ただし、タッチパネル１３は、任意の種類のものであってよく、例えば、シングルタッチ入力が可能な方式（例えば、抵抗膜方式）のものであってもよい。

本体装置２は、ハウジング１１の内部においてスピーカ（すなわち、図６に示すスピーカ８８）を備えている。図３に示すように、ハウジング１１の主面には、スピーカ孔１１ａおよび１１ｂが形成される。そして、スピーカ８８の出力音は、これらのスピーカ孔１１ａおよび１１ｂからそれぞれ出力される。

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

図３に示すように、本体装置２は、スロット２３を備える。スロット２３は、ハウジング１１の上側面に設けられる。スロット２３は、所定の種類の記憶媒体を装着可能な形状を有する。所定の種類の記憶媒体は、例えば、ゲームシステム１およびそれと同種の情報処理装置に専用の記憶媒体（例えば、専用メモリカード）である。所定の種類の記憶媒体は、例えば、本体装置２で利用されるデータ（例えば、アプリケーションのセーブデータ等）、および／または、本体装置２で実行されるプログラム（例えば、アプリケーションのプログラム等）を記憶するために用いられる。また、本体装置２は、電源ボタン２８を備える。

本体装置２は、下側端子２７を備える。下側端子２７は、本体装置２がクレードルと通信を行うための端子である。本実施形態において、下側端子２７は、ＵＳＢコネクタ（より具体的には、メス側コネクタ）である。上記一体型装置または本体装置２単体をクレードルに載置した場合、ゲームシステム１は、本体装置２が生成して出力する画像を据置型モニタに表示することができる。また、本実施形態においては、クレードルは、載置された上記一体型装置または本体装置２単体を充電する機能を有する。また、クレードルは、ハブ装置（具体的には、ＵＳＢハブ）の機能を有する。

図４は、左コントローラ３の一例を示す六面図である。図４に示すように、左コントローラ３は、ハウジング３１を備える。本実施形態においては、ハウジング３１は、縦長の形状、すなわち、図４における上下方向（図４に示すｚ軸方向）に長い形状である。左コントローラ３は、本体装置２から外された状態において、縦長となる向きで把持されることも可能である。ハウジング３１は、縦長となる向きで把持される場合に片手、特に左手で把持可能な形状および大きさをしている。また、左コントローラ３は、横長となる向きで把持されることも可能である。左コントローラ３が横長となる向きで把持される場合には、両手で把持されるようにしてもよい。

左コントローラ３は、方向入力デバイスの一例である左アナログスティック（以下、左スティックと呼ぶ）３２を備える。図４に示すように、左スティック３２は、ハウジング３１の主面に設けられる。左スティック３２は、方向を入力することが可能な方向入力部として用いることができる。ユーザは、左スティック３２を傾倒することによって傾倒方向に応じた方向の入力（および、傾倒した角度に応じた大きさの入力）が可能である。なお、左コントローラ３は、方向入力部として、アナログスティックに代えて、十字キーまたはスライド入力が可能なスライドスティック等を備えるようにしてもよい。また、本実施形態においては、左スティック３２を押下する入力が可能である。

左コントローラ３は、各種操作ボタンを備える。左コントローラ３は、ハウジング３１の主面上に４つの操作ボタン３３～３６（具体的には、右方向ボタン３３、下方向ボタン３４、上方向ボタン３５、および左方向ボタン３６）を備える。更に、左コントローラ３は、録画ボタン３７および－（マイナス）ボタン４７を備える。左コントローラ３は、ハウジング３１の側面の左上に第１Ｌボタン３８およびＺＬボタン３９を備える。また、左コントローラ３は、ハウジング３１の側面の、本体装置２に装着される際に装着される側の面に第２Ｌボタン４３および第２Ｒボタン４４を備える。これらの操作ボタンは、本体装置２で実行される各種プログラム（例えば、ＯＳプログラムやアプリケーションプログラム）に応じた指示を行うために用いられる。

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

図５は、右コントローラ４の一例を示す六面図である。図５に示すように、右コントローラ４は、ハウジング５１を備える。本実施形態においては、ハウジング５１は、縦長の形状、すなわち、図５における上下方向（図５に示すｚ軸方向）に長い形状である。右コントローラ４は、本体装置２から外された状態において、縦長となる向きで把持されることも可能である。ハウジング５１は、縦長となる向きで把持される場合に片手、特に右手で把持可能な形状および大きさをしている。また、右コントローラ４は、横長となる向きで把持されることも可能である。右コントローラ４が横長となる向きで把持される場合には、両手で把持されるようにしてもよい。

右コントローラ４は、左コントローラ３と同様、方向入力部として右アナログスティック（以下、右スティックと呼ぶ）５２を備える。本実施形態においては、右スティック５２は、左コントローラ３の左スティック３２と同じ構成である。また、右コントローラ４は、アナログスティックに代えて、十字キーまたはスライド入力が可能なスライドスティック等を備えるようにしてもよい。また、右コントローラ４は、左コントローラ３と同様、ハウジング５１の主面上に４つの操作ボタン５３～５６（具体的には、Ａボタン５３、Ｂボタン５４、Ｘボタン５５、およびＹボタン５６）を備える。更に、右コントローラ４は、＋（プラス）ボタン５７およびホームボタン５８を備える。また、右コントローラ４は、ハウジング５１の側面の右上に第１Ｒボタン６０およびＺＲボタン６１を備える。また、右コントローラ４は、左コントローラ３と同様、第２Ｌボタン６５および第２Ｒボタン６６を備える。

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

図６は、本体装置２の内部構成の一例を示すブロック図である。本体装置２は、図３に示す構成の他、図６に示す各構成要素８１～９１、９７、および９８を備える。これらの構成要素８１～９１、９７、および９８のいくつかは、電子部品として電子回路基板上に実装されてハウジング１１内に収納されてもよい。

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

本体装置２は、自身に内蔵される内部記憶媒体の一例として、フラッシュメモリ８４およびＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８５を備える。フラッシュメモリ８４およびＤＲＡＭ８５は、プロセッサ８１に接続される。フラッシュメモリ８４は、主に、本体装置２に保存される各種のデータ（プログラムであってもよい）を記憶するために用いられるメモリである。ＤＲＡＭ８５は、情報処理において用いられる各種のデータを一時的に記憶するために用いられるメモリである。

本体装置２は、スロットインターフェース（以下、「Ｉ／Ｆ」と略記する。）９１を備える。スロットＩ／Ｆ９１は、プロセッサ８１に接続される。スロットＩ／Ｆ９１は、スロット２３に接続され、スロット２３に装着された所定の種類の記憶媒体（例えば、専用メモリカード）に対するデータの読み出しおよび書き込みを、プロセッサ８１の指示に応じて行う。

プロセッサ８１は、フラッシュメモリ８４およびＤＲＡＭ８５、ならびに上記各記憶媒体との間でデータを適宜読み出したり書き込んだりして、上記の情報処理を実行する。

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

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

プロセッサ８１は、上述の左側端子１７、右側端子２１、および下側端子２７に接続される。プロセッサ８１は、左コントローラ３と有線通信を行う場合、左側端子１７を介して左コントローラ３へデータを送信するとともに、左側端子１７を介して左コントローラ３から操作データを受信する。また、プロセッサ８１は、右コントローラ４と有線通信を行う場合、右側端子２１を介して右コントローラ４へデータを送信するとともに、右側端子２１を介して右コントローラ４から操作データを受信する。また、プロセッサ８１は、クレードルと通信を行う場合、下側端子２７を介してクレードルへデータを送信する。このように、本実施形態においては、本体装置２は、左コントローラ３および右コントローラ４との間で、それぞれ有線通信と無線通信との両方を行うことができる。また、左コントローラ３および右コントローラ４が本体装置２に装着された一体型装置または本体装置２単体がクレードルに装着された場合、本体装置２は、クレードルを介してデータ（例えば、画像データや音声データ）を据置型モニタ等に出力することができる。

ここで、本体装置２は、複数の左コントローラ３と同時に（換言すれば、並行して）通信を行うことができる。また、本体装置２は、複数の右コントローラ４と同時に（換言すれば、並行して）通信を行うことができる。したがって、複数のユーザは、左コントローラ３および右コントローラ４のセットをそれぞれ用いて、本体装置２に対する入力を同時に行うことができる。一例として、第１ユーザが左コントローラ３および右コントローラ４の第１セットを用いて本体装置２に対して入力を行うと同時に、第２ユーザが左コントローラ３および右コントローラ４の第２セットを用いて本体装置２に対して入力を行うことが可能となる。

本体装置２は、タッチパネル１３の制御を行う回路であるタッチパネルコントローラ８６を備える。タッチパネルコントローラ８６は、タッチパネル１３とプロセッサ８１との間に接続される。タッチパネルコントローラ８６は、タッチパネル１３からの信号に基づいて、例えばタッチ入力が行われた位置を示すデータを生成して、プロセッサ８１へ出力する。

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

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

本体装置２は、電力制御部９７およびバッテリ９８を備える。電力制御部９７は、バッテリ９８およびプロセッサ８１に接続される。また、図示しないが、電力制御部９７は、本体装置２の各部（具体的には、バッテリ９８の電力の給電を受ける各部、左側端子１７、および右側端子２１）に接続される。電力制御部９７は、プロセッサ８１からの指令に基づいて、バッテリ９８から上記各部への電力供給を制御する。

また、バッテリ９８は、下側端子２７に接続される。外部の充電装置（例えば、クレードル）が下側端子２７に接続され、下側端子２７を介して本体装置２に電力が供給される場合、供給された電力がバッテリ９８に充電される。

図７は、本体装置２と左コントローラ３および右コントローラ４との内部構成の一例を示すブロック図である。なお、本体装置２に関する内部構成の詳細については、図６で示しているため図７では省略している。

左コントローラ３は、本体装置２との間で通信を行う通信制御部１０１を備える。図７に示すように、通信制御部１０１は、端子４２を含む各構成要素に接続される。本実施形態においては、通信制御部１０１は、端子４２を介した有線通信と、端子４２を介さない無線通信との両方で本体装置２と通信を行うことが可能である。通信制御部１０１は、左コントローラ３が本体装置２に対して行う通信方法を制御する。すなわち、左コントローラ３が本体装置２に装着されている場合、通信制御部１０１は、端子４２を介して本体装置２と通信を行う。また、左コントローラ３が本体装置２から外されている場合、通信制御部１０１は、本体装置２（具体的には、コントローラ通信部８３）との間で無線通信を行う。コントローラ通信部８３と通信制御部１０１との間の無線通信は、例えばＢｌｕｅｔｏｏｔｈ（登録商標）の規格に従って行われる。

また、左コントローラ３は、例えばフラッシュメモリ等のメモリ１０２を備える。通信制御部１０１は、例えばマイコン（マイクロプロセッサとも言う）で構成され、メモリ１０２に記憶されるファームウェアを実行することによって各種の処理を実行する。

左コントローラ３は、各ボタン１０３（具体的には、ボタン３３～３９、４３、４４、および４７）を備える。また、左コントローラ３は、左スティック３２を備える。各ボタン１０３および左スティック３２は、自身に対して行われた操作に関する情報を、適宜のタイミングで繰り返し通信制御部１０１へ出力する。

左コントローラ３は、慣性センサを備える。具体的には、左コントローラ３は、加速度センサ１０４を備える。また、左コントローラ３は、角速度センサ１０５を備える。本実施形態においては、加速度センサ１０４は、所定の３軸（例えば、図４に示すｘｙｚ軸）方向に沿った加速度の大きさを検出する。なお、加速度センサ１０４は、１軸方向あるいは２軸方向の加速度を検出するものであってもよい。本実施形態においては、角速度センサ１０５は、所定の３軸（例えば、図４に示すｘｙｚ軸）回りの角速度を検出する。なお、角速度センサ１０５は、１軸回りあるいは２軸回りの角速度を検出するものであってもよい。加速度センサ１０４および角速度センサ１０５は、それぞれ通信制御部１０１に接続される。そして、加速度センサ１０４および角速度センサ１０５の検出結果は、適宜のタイミングで繰り返し通信制御部１０１へ出力される。

通信制御部１０１は、各入力部（具体的には、各ボタン１０３、左スティック３２、各センサ１０４および１０５）から、入力に関する情報（具体的には、操作に関する情報、またはセンサによる検出結果）を取得する。通信制御部１０１は、取得した情報（または取得した情報に所定の加工を行った情報）を含む操作データを本体装置２へ送信する。なお、操作データは、所定時間に１回の割合で繰り返し送信される。なお、入力に関する情報が本体装置２へ送信される間隔は、各入力部について同じであってもよいし、同じでなくてもよい。

上記操作データが本体装置２へ送信されることによって、本体装置２は、左コントローラ３に対して行われた入力を得ることができる。すなわち、本体装置２は、各ボタン１０３および左スティック３２に対する操作を、操作データに基づいて判別することができる。また、本体装置２は、左コントローラ３の動きおよび／または姿勢に関する情報を、操作データ（具体的には、加速度センサ１０４および角速度センサ１０５の検出結果）に基づいて算出することができる。

左コントローラ３は、電力供給部１０８を備える。本実施形態において、電力供給部１０８は、バッテリおよび電力制御回路を有する。図示しないが、電力制御回路は、バッテリに接続されるとともに、左コントローラ３の各部（具体的には、バッテリの電力の給電を受ける各部）に接続される。

図７に示すように、右コントローラ４は、本体装置２との間で通信を行う通信制御部１１１を備える。また、右コントローラ４は、通信制御部１１１に接続されるメモリ１１２を備える。通信制御部１１１は、端子６４を含む各構成要素に接続される。通信制御部１１１およびメモリ１１２は、左コントローラ３の通信制御部１０１およびメモリ１０２と同様の機能を有する。したがって、通信制御部１１１は、端子６４を介した有線通信と、端子６４を介さない無線通信（具体的には、Ｂｌｕｅｔｏｏｔｈ（登録商標）の規格に従った通信）との両方で本体装置２と通信を行うことが可能であり、右コントローラ４が本体装置２に対して行う通信方法を制御する。

右コントローラ４は、左コントローラ３の各入力部と同様の各入力部を備える。具体的には、各ボタン１１３、右スティック５２、慣性センサ（加速度センサ１１４および角速度センサ１１５）を備える。これらの各入力部については、左コントローラ３の各入力部と同様の機能を有し、同様に動作する。

右コントローラ４は、電力供給部１１８を備える。電力供給部１１８は、左コントローラ３の電力供給部１０８と同様の機能を有し、同様に動作する。

［本実施形態におけるゲーム処理の概要］
次に、本実施形態に係るゲームシステム１で実行されるゲーム処理の動作概要を説明する。まず、本実施形態で想定するゲームについて説明する。図８は、本実施形態に係るゲームの画面例である。当該ゲームは、仮想３次元空間（以下、仮想空間と呼ぶ）内において、３人称視点で表示されるプレイヤキャラクタオブジェクト（以下、ＰＣと呼ぶ）２０１を操作するゲームである。図８の例では、ＰＣ２０１の他、第１キャラクタオブジェクト（以下、第１キャラクタと呼ぶ）が複数体表示されている。また、画面右上には、運搬物オブジェクト（以下、単に運搬物と呼ぶ）が１つ表示されている。

次に、上記第１キャラクタについて説明する。当該第１キャラクタは、ＰＣ２０１に関連付けられているＮＰＣ（ノンプレイヤキャラクタ）である。当該第１キャラクタは、ＡＩ制御によって、ある程度自律的に行動する、生物的なキャラクタオブジェクトである。ここで、本ゲームでは、「隊列」の概念がある。当該「隊列」は、１体の「リーダー」と複数の「メンバー」で構成され得る。「リーダー」はＰＣ２０１である。上記第１キャラクタは、「メンバー」となり得る。上記第１キャラクタは、隊列に所属していない状態でゲームフィールド上に点在しており、ユーザが所定の操作を行うことで、所定の第１キャラクタを自身の隊列に加えることができる。本ゲームでは、ＰＣ２０１の移動は、この「隊列」単位での移動となる。そのため、当該第１キャラクタは、基本的には、ＰＣ２０１の移動に追従して自動的に移動する。

ここで、本実施形態では、第１キャラクタは複数の種類に分かれており、各種類でその外観や特性（性能）が異なっている。本実施形態では一例として、第１キャラクタが４種類ある場合を例に説明する。また、本実施形態では、各種別毎にその外観の基調となる色が種類毎に異なっているとし、具体的には、赤色、青色、白色、黄色であるとする。そのため、以下の説明では、第１キャラクタの各種類毎に、「赤キャラクタ」、「青キャラクタ」、「白キャラクタ」、「黄キャラクタ」と称する。図８の例では、上記隊列のメンバーである第１キャラクタが合計１２体おり、各種類毎に略縦列状に並んでいる様子を示している。その内訳としては、左の縦列から順に、青キャラクタが２体、白キャラクタが３体、赤キャラクタが４体、黄キャラクタが３体となっている。

本ゲームでは、ユーザが所定の操作を行うことで、ＰＣ２０１に、当該第１キャラクタへ所定の指示を出させることができる。この指示に基づき、第１キャラクタは様々なアクションを行う。つまり、本ゲームは、第１キャラクタに指示を出して様々なアクションを行わせることでゲームを進行させることが可能なゲームである。第１キャラクタに行わせるアクションの一例として、敵キャラクタ（図示せず）を攻撃させたり、アイテムを取得させたり、所定の運搬物を所定の位置に運搬させることができる。

第１キャラクタへの指示の出し方について説明する。本実施形態では、ＰＣ２０１が、アクションを起こして欲しいオブジェクトの近傍に着地するよう第１キャラクタを「投擲」することで、第１キャラクタへの指示を出すことができる。着地した第１キャラクタは、近傍にあるオブジェクトの種類などに応じた所定のアクションを実行する。例えば、隊列内の第１キャラクタからいずれか１体を選択し、敵キャラクタの近くに着地するよう当該第１キャラクタを投擲すると、投げられた第１キャラクタは、着地後、その敵キャラクタへの攻撃を開始する（その攻撃力や攻撃速度は、種類毎に異なる）。つまり、この場合は、投擲することで「攻撃指示」を出したことになる。更に、同じ敵キャラクタに向けて追加で第１キャラクタを投擲（攻撃指示）することで、攻撃させる第１キャラクタ数を増加させることもできる。同様に、例えば、上記運搬物の近くに第１キャラクタを投擲することで、所定の目的地に向けて当該運搬物を運搬させることができる。つまり、「運搬指示」となる。本実施形態は、特に、この運搬物を運搬させる局面に関する処理である。より具体的には、運搬中に再生される「運搬ボイス」の再生制御に関するものである。以下、この運搬に係る動きと本実施形態の処理概要について、画面例を用いて説明する。

まず、上記運搬の開始と運搬させる第１キャラクタの増員に係る動きの一例を図を用いて説明する。上記図８の状態において、ユーザが上記運搬物を運搬させたい場合を想定する。この場合、ユーザは所定の選択操作を行うことで、投擲対象として赤キャラクタを選択する。そして、ユーザが所定の投擲操作を行うことで、図９で示すように、ＰＣ２０１に、当該赤キャラクタを運搬物に向けて投擲する動作を行わせることができる。

その後、図１０で示すように、投げられた赤キャラクタは運搬物の側に着地する。そして、図１１で示すように、赤キャラクタは運搬物を持ち上げて、所定の目的地に向けて運搬を開始する。この際、当該運搬物に関連付けられたグループである「運搬グループ」が作成される。当該運搬グループは、その運搬物を運搬する第１キャラクタ（以下、当該第１キャラクタのことを構成メンバーと呼ぶ）で構成されるグループである。但し、この時点では、当該運搬グループの構成メンバーは、当該赤キャラクタ１体だけである。また、詳細は後述するが、運搬中は、第１キャラクタが発する「かけ声」として、後述するような運搬ボイス（図１１では吹き出しで示している）が再生される。

更に、当該運搬物（運搬グループ）に向けて他の第１キャラクタを投擲することで、運搬グループの構成メンバーを増やすことができる。例えば、図１２に示すように、白キャラクタを１体投擲した場合、図１３に示すように、当該白キャラクタが運搬グループに追加され、２体の第１キャラクタによって運搬物が運搬される状態に変化する。

この後、第１キャラクタを更に投擲する操作を行うことで、運搬グループの構成メンバーを更に増やすことができる。図１４は、ユーザが、例えば投擲操作に割り当てられているボタンを連打することによって、投擲操作が連続的に行われている様子を示している。更に、図１５は、上記隊列のメンバー全員を運搬グループに追加した（運搬グループに投擲した）後の状態を示している。図１５では、計１２体の第１キャラクタで運搬物を運搬している状態である。なお、本実施形態では、運搬グループの構成メンバーが増えるに連れて、運搬物の運搬速度も速くなっていく。つまり、より多くの第１キャラクタに運搬させることで、運搬物をより速やかに目的地に運ぶことができる。

また、本実施形態では、ユーザが所定の解散操作を行うことで、運搬途中であっても、運搬グループを解散させることができる。例えば、ユーザが解散操作を行うと、運搬グループは解散され、運搬グループの構成メンバーは全員ＰＣ２０１の元に戻ってくる（つまり、運搬中の第１キャラクタをＰＣ２０１のもとに呼び寄せるような動きになる）。また、この際、運搬物は、その場に放置される。また、その他、運搬グループが目的地に到達した場合は、自動的に運搬グループは解散する。

次に、運搬ボイスに関して説明する。上記のように、第１キャラクタが運搬物の運搬中は、「かけ声」としての運搬ボイスが再生される。上記図１１～図１５で示している吹き出しは、運搬ボイスが再生されていることを示している。なお、これらの図では、１つの吹き出しが１回分の再生であることを示している。例えば、上記図１３の吹き出しの場合、２つの運搬ボイスが同時に再生されていることを示している。そして、本実施形態では、運搬グループの構成メンバー数が増えるにつれて、同時に再生される運搬ボイス数も増えるような制御を行っている。より具体的には、運搬グループ内の第１キャラクタの総数と、その種類の比率に応じて、運搬ボイスの同時再生数と、再生される音声内容を決定している。なお、ここでいう「同時再生」は、厳密な意味で各運搬ボイスの再生開始のタイミングが同じである場合に限らず、実質的に同時に再生されているよう聞こえる程度であれば、多少再生タイミングがずれている場合も含む。

ここで、運搬ボイスの同時再生数等の決め方を説明する前に、その前提として、各運搬ボイスの定義や音声データの生成手法に関して説明する。まず、本実施形態では、声優が発声した音声（運搬ボイス）を収録したものを音声データとして記録している。そして、本実施形態では、第１キャラクタの種類毎に異なる声優による運搬ボイスの音声データが用意されるものとする。つまり、第１キャラクタの種類毎に声色が異なっていることになる。また、運搬ボイスの台詞については、種類毎に異なっていてもよいし、同じ台詞であってもよい。台詞自体が異なる場合は、例えば、赤キャラクタの運搬ボイスは、声優Ａによる「エッホ！」であり、白キャラクタの運搬ボイスは、声優Ｂによる「エホエホ」のように、キャラクタの種類毎に声優および台詞そのものが異なることになる。また、台詞自体が同じ場合は、例えば「エッホ」という台詞のかけ声を収録する際に、本実施形態では４種類の第１キャラクタがいるため、４人の異なる声優が発声した「エッホ」の声を収録することで、各種類に対応する運搬ボイスに係る音声データが生成される。この場合は、発声している人物が異なるため、声質や声色等も異なることになり、同じ台詞であっても、異なる聞こえ方となる。

更に、本実施形態では、第１キャラクタの種類毎に、４種類（４つ）の音声データを用意する。例えば、赤キャラクタの運搬ボイスの音声データとして、同じ声優による、それぞれ異なる４種類の台詞の音声データを用意してもよい。あるいは、同じ声優で同じ台詞ではあるが、それぞれ個別に収録した音声データを４つ用意してもよい。同じ声優による同じ台詞であっても、別々のタイミングで収録しているため、厳密には全く同じ波形とはならず、多少のばらつきが含まれた音声データとなり得る。そのため、僅かながら聞こえ方が異なることもあり得る。そして、最終的には、第１キャラクタの種別毎に、このような４種類の音声データのうちのいずれか１つが選ばれて、運搬ボイスとして再生されることになる。

このように、本実施形態では、第１キャラクタの種類毎に運搬ボイス（音声データ）が異なり、かつ、同種の第１キャラクタについても、（同じ声優による）４種類の運搬ボイスが予め用意されている。このことを前提として、次に、本実施形態での運搬ボイスの決め方の概要を説明する。

［同時再生数の決定］
本実施形態では、まず、運搬グループの構成メンバー（第１キャラクタ）の総数に基づき、同時に再生する運搬ボイスの数（以下、同時再生数）を、抽選で決定する。図１６に、本実施形態での、第１キャラクタの総数と同時再生数の相関関係の一例を示す。基本的には、構成メンバーの総数が増えるほど、同時再生数が増える確率が高くなる。但し、本実施形態では、単純に総数に比例して同時再生数を増やすのではなく、総数の増加分に対する同時再生数の増加分が逓減するようにしている。具体的には、図１６に示すように、本実施形態では、同時再生数は、構成メンバーの総数が１体の場合は１音確定、２体の場合は２音確定、６体の場合に３音確定、１０体以上では４音確定としている。つまり、構成メンバーの総数が増えるほど同時再生数の増加分が逓減している。そして、総数が３体～５体の場合は、同時再生数として２音または３音が抽選で選ばれる。例えば、２音の当選率および３音の当選率として、総数が３体の場合はそれぞれ７５％、２５％であり、総数が４体の場合はそれぞれ５０％、５０％であり、総数が５体の場合はそれぞれ２５％、７５％となる。７～９体の場合も同様に、同時再生数として３音または４音が抽選で選ばれる。そして、１０体以上は４音確定となる。このように、運搬グループの構成メンバーの総数に基づいて同時再生数を抽選で決定することで、ある総数（例えば４体）の場合に再生される同時再生数について、ある程度のランダム性をもたせている。

同時再生数が決まれば、次に、実際に再生する運搬ボイスの内容を決定する。本実施形態では、以下のようにして決定している。まず、運搬ボイスを再生（発声）する第１キャラクタの種類（以下、再生担当種類）を抽選で決める。つまり、どの種類の第１キャラクタの音声を再生するのかを決める。ここで、抽選回数として、上記のようにして決められた同時再生音数を上限回数とする。例えば同時再生数が２音の場合は２回抽選が行われ、３音であれば、３回抽選が行われる。そして、各抽選における当選率は、運搬グループ内の第１キャラクタの種類の比率に基づいた当選率（確率）となるよう設定される。例えば、構成メンバーが赤キャラクタ１体、青キャラクタ１体の合計２体の場合、比率は１：１であるため、再生担当種類の当選率としてそれぞれ５０％が設定される。また、例えば赤キャラクタ３体、青キャラクタ１体の合計４体の場合、上記当選率は３：１の比率となるように設定される。具体的には、赤キャラクタは７５％、青キャラクタは２５％の当選率が設定される。また例えば、構成メンバーの総数が１０体で、赤５、青２、白２、黄１という構成の場合は、比率は５：２：２：１となり、それぞれ、５０％、２０％、２０％、１０％の当選率が設定される。

［再生する音声データの決定］
再生担当種類が決まれば、次に、当該種類毎に、再生する音声データを特定する。上記のように、本実施形態では第１キャラクタの種類毎に４種類の音声データを用意している。本実施形態では、この中から抽選で１つを決定する。本実施形態では、それぞれ２５％の当選率設定で抽選が行われるものとする。そのため、例えば、同時再生数が２音の場合で、再生担当種類が「赤キャラクタ、赤キャラクタ」となった場合を想定する。この場合、赤キャラクタに対応づけられている４種類の音声データのことをボイスＡ～ボイスＤと呼ぶとすると、ボイスＡとボイスＢが抽選で決定され、同時に再生されることもあり得る。あるいは、このような場合に、２音ともボイスＡ（同じ音声データ）が抽選で決定されることもあり得る。この場合は、同時にボイスＡが再生されることになり、結果的に、当該ボイスＡの再生音量が（１音だけで再生する場合より）大きくなり得る。

なお、他の実施形態では、上記４種類の音声データから抽選で決めることに限らず、当該４種類の音声データが所定の順番で選択されるようにしてもよい。

このように、運搬グループの構成メンバーの総数で同時再生数を決めつつ、第１キャラクタの種類の構成比率で再生担当種類を決めることで、例えば図１７で示すような運搬ボイスの再生ができる。図１７は、例えば上記総数が４体の場合で、その内訳が赤キャラクタ２体、青キャラクタ１体、白キャラクタ１体の場合の運搬ボイスの例を、右方向に時系列で示した模式図である。この図では運搬ボイスが４回再生されていることを示している。また、各運搬ボイスの再生開始～次の運搬ボイスの再生開始までの間隔（再生間隔）はＸ秒であるとする。図１７においては、１回目の再生では、赤キャラクタの運搬ボイス（以下、赤ボイスと呼ぶ）が２音同時再生されていることを示している。また、２回目の再生では３音同時再生で、青キャラクタの運搬ボイス（以下、青ボイスと呼ぶ：図１７では太字斜体で示している）１音と赤ボイス２音とが同時再生されていることを示している。３回目の再生では、白キャラクタの運搬ボイス（以下、白ボイスと呼ぶ：図１７では斜体で示している）１音と赤ボイス１音との２音同時再生されていることを示している。そして、４回目の再生では、３音同時再生されており、青ボイス１音、赤ボイス１音、白ボイス１音という内訳となっている。つまり、同時再生数については、上記のように抽選で決まるため、ある程度ランダム性を有していることが示される。また、各タイミングで再生される再生担当種類の内訳もそれぞれ異なっており、こちらもランダム性を有していることが示されている。

また、図１８～図２０に、それぞれ異なる第１キャラクタの構成比率の再生例を示す。それぞれ、４回分の運搬ボイスの再生を示している。図１８では、赤キャラクタ２体の構成であり、この場合は、上記図１６で示したように、同時再生数は２音確定となる。そのため、４回とも、「赤ボイス・赤ボイス」の組み合わせで２音同時再生となっている。また、図１９は、赤キャラクタ４体、白キャラクタ１体の比率の例である。この場合は、総数は５体のため、同時再生数は２～３音が抽選で決められる。この例では、２回目の運搬ボイスの時だけ２音同時再生、その他は３音同時再生となっている。また、構成比率が低い白ボイスは、２回目の時だけ再生されている。また、図２０は、赤キャラクタ４体、白キャラクタ２体、青キャラクタ３体の構成比率の例である。この場合は、総数は９体のため、上記図１６で示したように、同時再生数は３～４音が抽選で決定される。この例では、３回目だけ３音同時再生であることを示している。また、再生される運搬ボイスについては、多い順番に、赤ボイス（合計１０ボイス）、青ボイス（合計３ボイス）、白ボイス（合計２ボイス）となっている。図２０の例では、１回目の再生では赤ボイスのみが聞こえ、２回目の再生では赤ボイスと青ボイスとが聞こえることになる。更に３回目の再生では赤ボイスに白ボイスが混じっているように聞こえ、４回目の再生では、赤ボイス、白ボイス、青ボイスが混ざって聞こえることになる。上記のような再生制御により、再生される運搬ボイスについて、「生き物」らしさのある、より自然な感じの音声表現が可能となる。

なお、本実施形態では、構成メンバーが増えることで運搬速度も速くなるが、当該運搬速度の増加に連れて、運搬ボイスの再生速度も速くなっていくよう制御する。

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

［使用データについて］
まず、本ゲーム処理にて用いられる各種データに関して説明する。図２１は、本体装置２のＤＲＡＭ８５に記憶される各種データの一例を示すメモリマップである。本体装置２のＤＲＡＭ８５には、ゲームプログラム３０１、ＰＣデータ３０２、第１キャラクタデータ３０３、運搬ボイスデータ３０４、種類ボイス定義データ３０５、運搬物データ３０６、操作データ３０７、運搬グループ管理用データ３０８、等が記憶されている。

ゲームプログラム３０１は、本実施形態におけるゲーム処理を実行するためのプログラムである。当該プログラムには、上記のような運搬ボイスの再生制御を実現するためのプログラムも含まれている。

ＰＣデータ３０２は、上記ＰＣ２０１に関するデータである。図２２に、ＰＣデータ３０２のデータ構成の一例を示す。ＰＣデータ３０２には、ＰＣ位置・姿勢データ３２１、ＰＣ移動パラメータ３２２、および隊列データ３２３が少なくとも含まれている。

ＰＣ位置・姿勢データ３２１は、仮想空間内におけるＰＣ２０１の現在位置や現在の姿勢を示すデータである。

ＰＣ移動パラメータ３２２は、ＰＣ２０１の移動制御のために用いるデータである。例えば、ＰＣ移動パラメータ３２２には、ＰＣ２０１の移動方向や移動速度等を示すパラメータが含まれる。

隊列データ３２３は、ＰＣ２０１をリーダーとする上記隊列の内容を定義するデータである。隊列データ３２３には、当該隊列に加わっている第１キャラクタを特定するための情報が少なくとも含まれている。

その他、ＰＣデータ３０２には、ＰＣ２０１の外観を構成する各種データ（３次元モデルデータやテクスチャデータ等）やＰＣ２０１が行う各種動作のアニメーションを定義したデータ等が含まれる。

図２１に戻り、第１キャラクタデータ３０３は、上記第１キャラクタに関するデータである。第１キャラクタデータ３０３は、図２３に示すような項目を含むレコードの集合で構成されるデータベースである。図２３において、各レコードは、第１キャラＩＤ３３１、キャラ種類３３２、現在位置３３３、所属先３３４、行動状態３３５、行動パラメータ３３６の項目を少なくとも含む。

第１キャラＩＤ３８１は、第１オブジェクトを一意に識別するためのＩＤである。キャラ種類３３２は、その第１オブジェクトが、上述した４種類のうちのどの種類であるかを示すデータである。本例では、当該データの内容として、「赤」、「青」、「白」、「黄」、のいずれかが格納されるものとする。

現在位置３３３は、仮想ゲーム空間内における関連オブジェクトの現在位置を示す情報である。所属先３３４は、その第１キャラクタが現在、ＰＣ２０１の隊列に所属しているか否かを示すデータである。本例では、当該データの内容として、ＰＣの隊列に所属していれば「ＰＣ」が、所属していない場合は「未所属」が設定されるものとする。

行動状態３３５は、その第１キャラクタの現在の状態を示すデータである。当該第１キャラクタの状態としては、例えば、「待機中」、「移動中」、「投擲中」、「運搬中」、「攻撃中」、等が設定される。行動パラメータ３３６は、第１キャラクタの行動を制御するための各種パラメータである。例えば、上記行動状態３３５が「移動中」や「運搬中」であれば、移動方向や移動速度を示すパラメータが設定される。また、行動状態３３５が「攻撃中」の場合は、攻撃対象を示す情報や攻撃力等を示すパラメータが設定される。

その他、図示は省略するが、第１キャラクタデータ３０３の各レコードには、例えば第１キャラクタのＨＰ（ヒットポイント）や現在の姿勢を示す情報等、ゲーム処理に必要な各種の情報が含まれ得る。

図２１に戻り、運搬ボイスデータ３０４は、上記運搬ボイスの音声データである。具体的には、運搬ボイスデータ３０４は、図２４に示すような、ボイスＩＤ３４１および音声内容３４２の項目を含むレコードの集合で構成されるデータベースである。ボイスＩＤ３４１は、各運搬ボイスと特定するためのＩＤ（例えば音声データ名）であり、音声内容３４２は、その具体的な音声データである（例えばＷＡＶ形式のデータ）。

図２１に戻り、次に、種類ボイス定義データ３０５は、第１キャラクタの種類と、上記４種の運搬ボイスのデータとの対応関係を定義したデータである。種類ボイス定義データ３０５は、図２５に示すような項目を含むレコードの集合で構成されるデータベースである。図２５において、各レコードは、キャラ種類３５１、第１ボイス３５２、第２ボイス３５３、第３ボイス３５４、第４ボイス３５５の項目を少なくとも含む。キャラ種類３５１は、上記４種類の第１キャラクタのうちのいずれかの種類を特定するデータである。そして、種類毎に、第１ボイス３５２、第２ボイス３５３、第３ボイス３５４、第４ボイス３５５として、上記運搬ボイスデータ３０４のボイスＩＤ３４１が対応づけて格納されている。

図２１に戻り、次に、運搬物データ３０６は、上記運搬物に関するデータである。図２６に、運搬物データ３０６のデータ構成の一例を示す。運搬物データ３０６は、運搬物ＩＤ３６１および現在位置３６２の項目を少なくとも含むレコードの集合で構成されるデータベースである。運搬物ＩＤ３６１は、各運搬物を一意に特定するＩＤである。現在位置３６２は、その運搬物の仮想空間内における現在位置を示すデータである。この他、図示は省略するが、運搬物の外観を構成するための各種情報や、運搬物の重量を示す情報（運搬速度に影響を及ぼす）、その他、運搬物の特性等を定義した情報等も運搬物データ３０６に含まれ得る。

図２１に戻り、次に、操作データ３０７は、上記ユーザが操作するコントローラから得られるデータである。すなわち、ユーザが行った操作内容を示すデータである。図２７に、操作データ３０７のデータ構成の一例を示す。操作データ３０７には、デジタルボタンデータ３７１と、右スティックデータ３７２と、左スティックデータ３７３と、右慣性センサデータ３７４と、左慣性センサデータ３７５とが少なくとも含まれている。デジタルボタンデータ３７１は、コントローラが有する各種ボタンの押下状態を示すデータである。右スティックデータ３７２は、上記右スティック５２に対する操作内容を示すためのデータである。具体的には、ｘ、ｙの２次元のデータが含まれる。左スティックデータ３７３は、上記左スティック３２に対する操作内容を示すためのデータである。右慣性センサデータ３７４は、右コントローラ４の加速度センサ１１４や角速度センサ１１５の慣性センサの検出結果を示すデータである。具体的には、３軸の加速度データや３軸の角速度データが含まれる。左慣性センサデータ３７５は、左コントローラ３の加速度センサ１０４や角速度センサ１０５の慣性センサの検出結果を示すデータである。

図２１に戻り、運搬グループ管理用データ３０８は、上記運搬グループを管理するためのデータである。運搬グループ管理用データ３０８には、グループ基本データ３０９、構成メンバーデータ３１０、再生ボイス指定データ３１１が含まれている。

グループ基本データ３０９は、運搬グループの基本的な情報を示すデータである。具体的には、グループ基本データ３０９は、図２８に示すような項目を含むレコードの集合で構成されるデータベースである。図２８において、各レコードは、グループＩＤ３９１、運搬物ＩＤ３９２、目的地情報３９３、現在位置情報３９４、運搬速度パラメータ３９５、再生中フラグ３９６、仮想スピーカ位置情報３９７の項目を少なくとも含む。

グループＩＤ３９１は、各運搬グループを一意に特定するためのＩＤである（本実施形態では、運搬グループは複数グループが併存し得る）。

運搬物ＩＤ３９２は、運搬対象となる運搬物を示す上記運搬物データ３０６の運搬物ＩＤ３６１が設定されたものである。

目的地情報３９３は、その運搬グループの目的地を示す情報である。当該目的地は、ゲーム展開やゲーム状況等に応じて、運搬グループの作成時に適宜設定される。

現在位置情報３９４は、その運搬グループの現在位置を示す情報である。

運搬速度パラメータ３９５は、その運搬グループの運搬速度を定義するパラメータである。上記のように、運搬グループの構成メンバー数が多いほど、運搬速度は速くなるように設定される。

再生中フラグ３９６は、その運搬グループに係る上記運搬ボイスを現在再生中の状態であるか否かを示すフラグである。オンの場合は、運搬ボイスの再生中であることを示している。

仮想スピーカ位置情報３９７は、その運搬グループに係る運搬ボイスを発する仮想スピーカの位置を定義した情報である。本実施形態では、運搬ボイスを発する仮想スピーカーの数は１つだけであるとする。そして、その位置については、その運搬グループの構成メンバー群の重心位置であるとする。また、本実施形態では、このような重心位置が、上記現在位置情報３９４に対する相対的な位置として定義されるものとする（つまり、運搬グループの移動に追従して仮想スピーカの位置も移動することになる）。

図２１に戻り、次に、構成メンバーデータ３１０は、各運搬グループを構成する構成メンバー（第１キャクタタ）を示すデータである。具体的は、構成メンバーデータ３１０は、図２９に示すような、グループＩＤ４０１および構成メンバーＩＤ４０２を含むレコードの集合で構成されるデータベースである。グループＩＤ４０１は、上記運搬グループを特定するためのＩＤであり、上記グループ基本データ３０９におけるグループＩＤ３９１に対応するものである。構成メンバーＩＤ４０２は、その運搬グループの構成メンバーである各第１キャラクタの第１キャラＩＤ３３１が設定されたものである。

図２１に戻り、次に、再生ボイス指定データ３１１は、その運搬グループに係る運搬ボイスとしてどの音声データを用いるのかを示すデータである。具体的には、再生ボイス指定データ３１１は、図３０に示すような項目を含むレコードの集合で構成されるデータベースである。図３０において、各レコードは、グループＩＤ４１１、再生用ボイスＩＤ４１２、再生速度情報４１３の項目を含む。グループＩＤ４１１は、運搬グループを特定するためのＩＤであり、上記グループ基本データ３０９におけるグループＩＤ３９１に対応するものである。再生用ボイスＩＤ４１２、再生速度情報４１３は、グループ毎に、４件分のデータが割り当てられている。再生用ボイスＩＤ４１２は、運搬ボイスとして再生する音声データの上記ボイスＩＤ３４１が設定されたものである。再生速度情報４１３は、当該運搬ボイスに係る音声の再生速度を定義したパラメータである。

その他、ゲーム処理に必要な各種データも適宜生成され、ＤＲＡＭ８５に格納される。

［プロセッサ８１が実行する処理の詳細］
次に、本実施形態におけるゲーム処理の詳細を説明する。なお、ここでは主に、上記のような運搬ボイスの再生制御に関する制御について説明し、その他の各種ゲーム処理については詳細な説明は割愛する。本実施形態では、１以上のプロセッサが１以上のメモリに記憶された上記プログラムを読み込んで実行することにより、以下に示すフローチャートが実現される。なお、当該フローチャートは、処理過程の単なる一例にすぎない。そのため、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判定ステップで利用される閾値も、単なる一例であり、必要に応じて他の値を採用してもよい。

図３１は、本実施形態に係るゲーム処理の詳細を示すフローチャートである。図３１のステップＳ２～Ｓ７の処理ループは、１フレーム毎に繰り返し実行される。

［ゲームの準備］
図３１において、ステップＳ１で、プロセッサ８１は、ゲーム準備処理を実行する。この処理では、プロセッサ８１は、仮想空間を構築し、ＰＣや第１キャラクタ、運搬物を適宜配置する。そして、当該仮想空間を仮想カメラで撮像してゲーム画像を生成し、出力する。また、プロセッサ８１は、ゲーム処理に必要な各種データをＤＲＡＭ８５に読み込み、各種フラグ等の変動するデータや変数については適宜初期化する。特に、運搬ボイスデータ３０４として運搬ボイスの音声データをこの時点でＤＲＡＭ８５に読み込んでおくことで、後述の処理において速やかな音声再生が開始できるようにしておく。

次に、ステップＳ２で、プロセッサ８１は、プレイヤキャラクタ制御処理を実行する。この処理では、ユーザの操作内容をＰＣ２０１の動作に反映させるための処理が行われる。具体的には、プロセッサ８１は、操作データ３０７を取得する。更に、その操作内容に基づいて、ＰＣ２０１に所定の動作を行わせる。例えば、移動や、第１キャラクタを投擲する動作、運搬グループを解散させる動作、等を行わせる。また、ＰＣ２０１の動作に応じて、第１キャラクタの所属先３３４、行動状態３３５、行動パラメータ３３６の内容が適宜更新される。例えば、第１キャラクタを投擲する動作が行われた場合、投擲される第１キャラクタの行動状態３３５に「投擲中」が設定され、行動パラメータ３３６には、投擲によって移動するための移動パラメータが適宜設定される。

次に、ステップＳ３で、プロセッサ８１は、運搬グループ管理処理を実行する。この処理では、ユーザの操作内容に基づき、運搬グループの作成等、運搬グループの構成を管理するための処理が行われる。図３２は、当該運搬グループ管理処理の詳細を示すフローチャートである。図３２において、まず、ステップＳ１１で、プロセッサ８１は、運搬グループを新規に作成する条件が満たされたか否かを判定する。当該条件は、例えば、運搬グループと関連付けられていない運搬物に対して、新たな運搬指示が行われたことである。上記のように、所定の第１キャラクタを当該運搬物の近くに投擲することによって、当該第１キャラクタに当該運搬物を運搬させる運搬指示を出すことができる。そのため、上記操作データ３０７等に基づいて、運搬グループと関連付けられていない運搬物の近傍に第１キャラクタを投擲する操作が行われたか否かを判定することで、新たな運搬指示が行われたか否かが判定される。この他、例えば、運搬グループと関連付けられていない運搬物と（投擲された）第１キャラクタとが接触したときに、当該条件が満たされたと判定してもよい。

上記判定の結果、運搬グループの新規作成条件が満たされた場合は（ステップＳ１１でＹＥＳ）、ステップＳ１２で、プロセッサ８１は、新たな運搬グループについての情報を上記運搬グループ管理用データ３０８に登録する。具体的には、まず、プロセッサ８１は、新たなグループＩＤを採番して、グループ基本データ３０９、構成メンバーデータ３１０、再生ボイス指定データのそれぞれについて新たなレコードを作成する。そして、構成メンバーデータ３１０については、上記投擲された第１キャラクタの第１キャラＩＤ３３１を構成メンバーＩＤ４０２に追加する（この時点では１体だけである）。また、これに伴い、当該第１キャラクタの行動状態３３５として「運搬中」が設定される。また、再生ボイス指定データ３１１については、この時点ではまだ具体的データは設定されないため、グループＩＤ４１１以外については例えばＮｕｌｌ値が設定される。次に、プロセッサ８１は、グループ基本データ３０９の内容を設定する。まず、プロセッサ８１は、運搬対象となる運搬物の運搬物ＩＤ３６１を、グループ基本データ３０９の運搬物ＩＤ３９２に設定する。次に、プロセッサ８１は、そのときのゲーム状況等に応じて目的地情報３９３を設定し、現在位置情報３９４も設定する。また、運搬速度パラメータ３９５については、この時点では構成メンバーは１体だけであるため、これに応じた運搬速度のパラメータが設定される。ここで、当該運搬速度パラメータ３９５の設定に際しては、運搬物の「重量」を考慮して設定してもよい（重い方が相対的に運搬速度は遅くなる）。すなわち、構成メンバーの総数、および、運搬物の「重量」に基づいて、運搬速度を設定してもよい。また、再生中フラグ３９６には、初期値としてオフが設定される。更に、プロセッサ８１は、構成メンバー群の重心位置（いわば、運搬グループの重心位置）を算出し、これに基づいて仮想スピーカ位置情報３９７を設定する。

一方、上記ステップＳ１１の判定の結果、運搬グループの新規作成条件が満たされていない場合は（ステップＳ１１でＮＯ）、上記ステップＳ１２の処理はスキップされ、次の処理に進められる。

次に、ステップＳ１３で、プロセッサ８１は、いずれかの運搬グループの解散条件が満たされたか否かを判定する。例えば、上記操作データ３０７に基づいて、解散指示操作が行われたか否かが判定される。また、本実施形態では、運搬グループが目的地に到達した場合も、解散条件が満たされたと判定される。当該判定の結果、解散条件が満たされた場合は（ステップＳ１３でＹＥＳ）、ステップＳ１４で、プロセッサ８１は、解散指示が出された運搬グループを解散する処理を行う。具体的には、プロセッサ８１は、当該解散指示が出された運搬グループの情報を運搬グループ管理用データ３０８から消去する。一方、解散条件が満たされていない場合は（ステップＳ１３でＮＯ）、ステップＳ１４の処理はスキップされて、次の処理に進められる。

次に、ステップＳ１５で、プロセッサ８１は、いずれかの運搬グループについて、その構成メンバー数が増加したか否かを判定する。上記のように、既存の運搬グループに対して第１キャラクタを投擲することで、その運搬グループの構成メンバーを増やすことができる。そのため、このような操作が行われたか否かや、あるいは、既存の運搬グループに新たに第１キャラクタが接触したか否かを判定することで、構成メンバーの増加の有無を判定できる。当該判定の結果、構成メンバーが増加した場合は（ステップＳ１５でＹＥＳ）、ステップＳ１６で、プロセッサ８１は、当該増加を反映するように運搬グループ管理用データ３０８を更新する。具体的には、プロセッサ８１は、まず、構成メンバーデータ３１０について、増加した第１キャラクタの第１キャラＩＤ３３１を構成メンバーＩＤ４０２に追加する（これに伴い、当該第１キャラクタの行動状態３３５の内容も適宜更新される）。更に、プロセッサ８１は、構成メンバーデータ３１０に基づいて追加後の構成メンバー数を算出し、その数に基づいて、グループ基本データ３０９の運搬速度パラメータ３９５を再設定する。すなわち、上述のように、構成メンバー数が増えていくほど、運搬速度も速くなっていくように設定される。また、仮想スピーカ位置情報３９７についても、増加後の構成メンバーの位置関係に基づいて運搬グループの重心が算出されることで、再設定される。その後、プロセッサ８１は、運搬グループ管理処理を終了する。

一方、上記判定の結果、運搬グループの構成メンバー数の増加が発生していない場合は（ステップＳ１５でＮＯ）、上記ステップＳ１６の処理はスキップされる。そして、プロセッサ８１は、運搬グループ管理処理を終了する。

なお、本実施形態では、運搬中においては構成メンバーが減少することがない前提で説明している。この点、他の実施形態で、運搬中に構成メンバー数が減少する場合は、構成メンバーの減少を反映するように運搬グループ管理用データ３０８（運搬速度パラメータ３９５等）を更新すればよい。

図３１に戻り、次に、ステップＳ４で、プロセッサ８１は、運搬グループ動作制御処理を実行する。当該処理では、運搬グループの移動制御と、上記運搬ボイスの再生制御が行われる。図３３は、当該運搬グループ動作制御処理の詳細を示すフローチャートである。図３３において、まず、ステップＳ２１で、プロセッサ８１は、（運搬グループが複数作成されている場合に）以下に説明する処理の対象とする運搬グループを１つ選択する。以下、ここで選択された運搬グループのことを処理対象グループと呼ぶ。

次に、ステップＳ２２で、プロセッサ８１は、処理対象グループに係る再生中フラグ３９６がオフであるか否かを判定する。つまり、処理対象グループについて、運搬ボイスが現在再生中の状態であるか否かが判定される。当該判定の結果、再生中フラグ３９６がオフの場合は（ステップＳ２２でＹＥＳ）、ステップＳ２３で、プロセッサ８１は、再生ボイス決定処理を実行する。

図３４は、当該再生ボイス決定処理の詳細を示すフローチャートである。図３４において、まず、ステップＳ４１で、プロセッサ８１は、構成メンバーデータ３１０および第１キャラクタデータ３０３を参照し、処理対象グループの構成メンバーの総数、および、第１キャラクタの種類毎の数を算出する。

次に、ステップＳ４２で、プロセッサ８１は、構成メンバーの総数に基づき、上記同時再生数を決定する。本実施形態では、上記のように抽選によって同時再生数を決定する。例えば、上記図１６で示した内容に相当する抽選テーブルを用いて、抽選処理が行われてもよい。以下、構成メンバーの総数に基づいた同時再生数の抽選処理のことを「第１抽選処理」と呼ぶ。

次に、ステップＳ４３で、プロセッサ８１は、処理対象グループの構成メンバーにおける第１キャラクタの種類の比率に基づいて、上記再生担当種類を決定する。当該処理では、まず、上記第１抽選処理で決定された同時再生数が抽選回数として設定される。そして、各抽選においては、上述したように、第１キャラクタの種類の比率に基づいた当選率が設定される。例えば、当該比率に基づく当選率について予め定義されている抽選テーブルを用いてもよいし、当該種類の比率に基づいてその都度当選率を算出するようにしてもよい。そして、当該設定された当選率を用いて、上記再生担当種類の抽選が行われる。以下、当該再生担当種類に係る抽選処理のことを「第２抽選処理」と呼ぶ。

次に、ステップＳ４４で、プロセッサ８１は、上記第２抽選処理で抽選された再生担当種類のぞれぞれについて、実際に再生する再生用ボイスを決定する。上述のように、本実施形態では、各種類につき４種類の運搬ボイス（４つの音声データ）が用意されている。そして、当選率をそれぞれ２５％とした抽選処理が行われ、いずれか１つの音声データが再生用ボイスとして決定される。以下、当該再生用ボイスに係る抽選処理のことを「第３抽選処理」と呼ぶ。

次に、ステップＳ４５で、プロセッサ８１は、上記第３抽選処理で決定された各再生用ボイスについて、その再生速度を決定する。具体的には、プロセッサ８１は、上記グループ基本データ３０９の運搬速度パラメータ（または、上記の構成メンバーの総数）に基づき、再生速度を決定する。上記のように、構成メンバーが多い（運搬速度が速い）ほど、再生速度も速くなるように決定される。そして、プロセッサ８１は、上記第３抽選処理の結果および当該決定された再生速度を再生ボイス指定データ３１１の再生速度情報４１３に設定する。その後、プロセッサ８１は、再生ボイス決定処理を終了する。

ここで、上記再生用ボイスの再生音量について補足する。本実施形態では、再生音量については、初期値として予め定義された音量で再生用ボイスが再生されるものとする。但し、他の実施形態では、例えば上記第３抽選処理で決定された結果として、同じ音声データが２つ以上ある場合、これらを個別に再生するのではなく、その音量を通常よりも大きくしたうえで、１つの再生用ボイスとして再生するようにしてもよい。また、更に他の実施形態では、各再生用ボイスの音量をランダムで決定してもよい。

図３３に戻り、次に、ステップＳ２４で、プロセッサ８１は、再生中フラグ３９６をオンに設定する。続くステップＳ２５で、プロセッサ８１は、上記再生ボイス指定データ３１１に基づき、各再生用ボイスの再生を開始する。なお、当該再生用ボイスが出力される仮想スピーカの位置については、上記仮想スピーカ位置情報３９７に基づく位置となる。

一方、上記ステップＳ２２の判定の結果、再生中フラグ３９６がオンの場合は（ステップＳ２２でＮＯ）、ステップＳ２６で、プロセッサ８１は、現在再生中の各再生用ボイスの再生処理を継続する。次に、ステップＳ２７で、プロセッサ８１は、再生用ボイスの再生が終了したか否かを判定する。なお、本実施形態では、運搬用ボイスに係る各音声データの再生時間は全て同じ時間に揃えられているものとする。他の実施形態では、各音声データの再生時間は異なっていてもよく、この場合は、最も長い再生時間の音声データの再生が終わったことをもって再生終了と判定してもよい。

当該判定の結果、再生が終了していない場合は（ステップＳ２７でＮＯ）、後述のステップＳ２９に処理が進められる。一方、再生が終了した場合は（ステップＳ２７でＹＥＳ）、ステップＳ２８で、プロセッサ８１は、再生中フラグ３９６をオフに設定する。

次に、ステップＳ２９で、プロセッサ８１は、運搬グループの移動制御を行う。すなわち、プロセッサ８１は、所定の目的地に向けて、運搬速度パラメータ３９５に基づいた速度で運搬グループ（運搬物および第１キャラクタ群）を移動させる。また、これに伴い、上記仮想スピーカの位置も移動することになる。また、当該移動に伴い、グループ基本データ３０９の現在位置情報３９４も適宜更新される。

次に、ステップＳ３０で、プロセッサ８１は、現在存在している全ての運搬グループについて上記のような処理を行ったか否かを判定する。その結果、まだ処理していない運搬グループが残っている場合（ステップＳ３０でＮＯ）、上記ステップＳ２１に戻り、処理が繰り返される。全ての運搬グループについて処理済みの場合は（ステップＳ３０でＹＥＳ）、プロセッサ８１は、運搬グループ動作制御処理を終了する。

図３１に戻り、次に、ステップＳ５で、プロセッサ８１は、運搬グループに属していない第１キャラクタの動作制御を行う。例えば、敵キャラクタを攻撃中の第１キャラクタがいれば、その攻撃行動を継続させる制御が行われる。また、その他、第１キャラクタ以外のＮＰＣ（敵キャラクタ等）の動作制御も適宜行われる。

［ゲーム画像の出力］
次に、ステップＳ６で、プロセッサ８１は、ゲーム画像を生成して、出力する。すなわち、プロセッサ８１は、上記のゲーム処理が反映された仮想ゲーム空間を仮想カメラで撮像し、ゲーム画像を生成する。そして、プロセッサ８１は、当該ゲーム画像を上記据え置き型モニタ等に出力する。

次に、ステップＳ７で、プロセッサ８１は、ゲーム処理の終了条件が満たされたか否かを判定する。例えば、ユーザによるゲーム終了指示操作があったか否かを判定する。その結果、終了条件が満たされていなければ（ステップＳ７でＮＯ）、上記ステップＳ２に戻り、処理が繰り返される。終了条件が満たされていれば（ステップＳ７でＹＥＳ）、プロセッサ８１は、当該ゲーム処理を終了する。

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

このように、本実施形態では、運搬グループの構成メンバーの総数に基づいて、運搬ボイスの同時再生数を抽選で決定している。更に、構成メンバーの種類の比率に基づき、再生する音声データを抽選で決定している。そのため、例えば、第１のタイミングにおける運搬ボイスでは赤キャラクタと青キャラクタの声が聞こえ、続く第２のタイミングでは赤キャラクタと白キャラクタの声が聞こえるという音声表現ができる。つまり、再生タイミング毎に、そのときの構成メンバーの総数と種類の内訳に応じて、同時再生される音声数と、上記再生担当種類の内訳を異ならせることができる。これにより、短いスパンでは、ユーザに聞こえてくる運搬ボイスの内容にランダム性を持たせることができる。つまり、短いスパンで見ると、多様な種類の運搬ボイスが聞こえてくることになり、不自然さや違和感のない、より「生き物」らしさのある音声表現ができる。その一方で、長期のスパンで見ると、聞こえてくる運搬ボイスの種類の比率が、運搬グループを構成している第１キャラクタの種類の比率に収束していくことになる。つまり、ある程度長い時間、運搬ボイスを聞いていれば、当該種類の比率に応じた運搬ボイスが聞こえてくることが認識できる。これにより、ユーザは、運搬グループを目視せずとも、その運搬ボイスを（ある程度の時間）聞いているだけで、その運搬グループを構成している第１オブジェクトの数や種別を認識できる。

［変形例］
なお、上記実施形態では、第１キャラクタの種類毎に、運搬ボイスとして４つの音声データを対応づける例を挙げた。これに限らず、他の実施形態では、各種類につき１つの音声データを対応づける構成であってもよい。この場合は、上記第２抽選処理によって再生担当種類が決まれば、必然的に再生用ボイス（音声データ）も決まることになるため、上述した第３抽選処理は省略できる。

また、上記実施形態では、運搬用ボイスが出力される仮想スピーカが１つだけの場合を例示した。他の実施形態では、仮想スピーカを複数用いてもよい。これにより、運搬ボイスが聞こえてくる位置をばらけさせ、より違和感の少ない聞こえ方とすることができる。例えば、運搬グループの構成メンバーを複数のサブグループに分け、当該サブグループ毎に１つの仮想スピーカを割り当てるようにしてもよい。但し、仮想スピーカ数が増えると、処理負荷が増大する可能性もあるため、処理負荷とのバランスを考慮して、例えば１つの運搬グループにつき仮想スピーカは３つ程度としてもよい。

また、上記同時再生数に関して、上記実施形態では構成メンバー総数に基づいた抽選（第１抽選処理）を行っていたが、他の実施形態では、総数と同時再生数の関係を固定的に予め定義したテーブルを用意しておき、抽選することなく同時再生数を決定してもよい。また、このテーブルについても、上記実施形態の場合と同様に、構成メンバー数が増えるほど、同時再生数の増加分が逓減するように定義してもよい。

また、上記図３１のフローチャートでは、ステップＳ２～Ｓ７の処理ループが１フレーム毎に繰り返し行われる例を示した。この点、他の実施形態では、一部の処理の繰り返し周期が異なる周期であってもよい。例えば、上記ステップＳ３に係る運搬グループ管理処理とステップＳ４に係る運搬グループ動作制御処理とは同期して処理されなくてもよく、繰り返し周期が異なっていてもよい。また、例えば、上記図３３～図３４のフローチャートに係る処理に関して、ステップＳ４１およびＳ４２の処理（グループ構成の把握と同時再生数の決定）と、ステップＳ４３～Ｓ４５（再生用ボイスの決定）およびＳ２５以降の再生用ボイスの再生に係る処理とは、その繰り返し周期が異なっていてもよい。例えば、前者のグループ構成の把握と同時再生数の決定に係る処理については、５フレーム周期で繰り返し実行され、後者の再生用ボイスの決定および再生に係る処理は、１フレーム周期で繰り返し実行されてもよい。

また、上記実施形態では、運搬物を（複数の）第１キャラクタに運搬させる局面を例として、上記運搬ボイスの再生制御について説明した。上記のようなボイスの再生制御は、上記のような局面に限らず、（第１キャラクタ等が）共同作業を行うような他の局面においても適用可能である。例えば、「かけ声」を再生しても違和感がないような共同作業を行う場合に、当該かけ声の再生制御として上記のような処理を適用してもよい。当該共同作業の例としては、例えば、重い岩や壁を「押す」あるいは「引っ張る」という作業に適用してもよい。その他、例えば、複数の第１キャラクタが同一の敵キャラクタを攻撃しているような場合に、攻撃中のかけ声を上記のような処理で再生制御してもよい。また、例えば、コンサートにおける観客の「合いの手」や、行進する隊列の人や馬の足音等に上記のような再生制御を適用してもよい。

また、運搬ボイス（音声データ）に関して、上記実施形態では、第１キャラクタの種類毎に異なる声優の声を用いる例を挙げた。他の実施形態では、全種類、同じ声優の声を用いつつ、台詞自体を種類毎に異なる台詞とすることで、第１キャラクタの種類毎の運搬ボイスを作成してもよい。その他、第１キャラクタの種類毎に、その聞こえ方が異なるような運搬ボイスとなるのであれば、どのような手法で運搬ボイスを作成してもよい。

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

１ ゲームシステム
２ 本体装置
３ 左コントローラ
４ 右コントローラ
８１ プロセッサ
８４ フラッシュメモリ
８５ ＤＲＡＭ

Claims (14)

1. 情報処理装置のコンピュータにおいて実行される情報処理プログラムであって、
   前記コンピュータに、
   仮想空間に配置された少なくとも１つのオブジェクトにより構成されるオブジェクトグループを管理するグループ管理処理を行わせ、
   前記オブジェクトの種類毎に少なくとも１つが関連付けられた再生用サウンドを取得するサウンド取得処理を行わせ、
   前記オブジェクトグループを構成する前記オブジェクトの種類毎の数の情報を取得する構成オブジェクト取得処理を行わせ、
   前記オブジェクトグループを構成する前記オブジェクトの総数である構成オブジェクト数に応じて、再生するサウンド数を決定するサウンド数決定処理を行わせ、
   前記オブジェクトグループを構成する前記オブジェクトの種類毎の数の比率に基づく確率で、当該オブジェクトの種類毎に関連付けられた前記再生用サウンドが抽選されるように、当該再生用サウンドを前記サウンド数だけ抽選するサウンド抽選処理を行わせ、
   前記サウンド抽選処理により抽選された前記再生用サウンドを再生する再生処理を行わせ、
   前記構成オブジェクト取得処理、前記サウンド数決定処理、前記サウンド抽選処理、および前記再生処理を継続的に繰り返し行わせる、情報処理プログラム。
2. 前記コンピュータに、前記構成オブジェクト数に応じた確率に基づいて、前記サウンド数を決定する前記サウンド数決定処理を行わせる、請求項１に記載の情報処理プログラム。
3. 前記コンピュータに、前記構成オブジェクト数が増えるほど前記サウンド数の増加分が逓減するようにして当該サウンド数を決定する前記サウンド数決定処理を行わせる、請求項１に記載の情報処理プログラム。
4. 前記コンピュータに、
   前記オブジェクトの種類毎に少なくとも２つが関連付けられた前記再生用サウンドを取得する前記サウンド取得処理を行わせ、
   前記オブジェクトの種類ごとに関連付けられた少なくとも２つの前記再生用サウンドの中から１つを選択するように前記サウンド抽選処理を行わせる、請求項１～３のいずれかに記載の情報処理プログラム。
5. 前記コンピュータに、前記サウンド抽選処理において同じ前記再生用サウンドが複数回抽選された場合、当該再生用サウンドを重ねて、または、当該再生用サウンドの音量が大きくなるように再生する前記再生処理を行わせる、請求項１に記載の情報処理プログラム。
6. 前記コンピュータに、前記構成オブジェクト数が多いほど前記再生用サウンドの再生速度が速くなるように再生する前記再生処理を行わせる、請求項１に記載の情報処理プログラム。
7. 前記コンピュータに、前記オブジェクトグループ毎に決定される、当該オブジェクトグループの前記構成オブジェクト数よりも小さな数であって１以上の数のサウンド再生位置から前記再生用サウンドを再生する前記再生処理を行わせる、請求項１に記載の情報処理プログラム。
8. 前記仮想空間には複数個の前記オブジェクトグループが存在し、
   前記コンピュータに、前記複数個のオブジェクトグループ毎に、前記構成オブジェクト取得処理、前記サウンド数決定処理、前記サウンド抽選処理、および前記再生処理を継続的に繰り返し行わせる、請求項１に記載の情報処理プログラム。
9. 前記コンピュータに、ランダムで決定された音量で前記再生用サウンドを再生する前記再生処理を行わせる、請求項１に記載の情報処理プログラム。
10. 前記コンピュータに更に、ユーザの操作入力に応じて、前記仮想空間に前記オブジェクトを配置させる、請求項１に記載の情報処理プログラム。
11. 前記コンピュータに更に、
    前記仮想空間に配置されたアイテムに対して前記オブジェクトに共同作業を行わせ、
    前記オブジェクトが前記共同作業を行っているときに、前記再生用サウンドを再生する再生処理を行わせる、請求項１０に記載の情報処理プログラム。
12. コンピュータを備える情報処理装置であって、
    前記コンピュータは、
    仮想空間に配置された少なくとも１つのオブジェクトにより構成されるオブジェクトグループを管理するグループ管理処理を行い、
    前記オブジェクトの種類毎に少なくとも１つが関連付けられた再生用サウンドを取得するサウンド取得処理を行い、
    前記オブジェクトグループを構成する前記オブジェクトの種類毎の数の情報を取得する構成オブジェクト取得処理を行い、
    前記オブジェクトグループを構成する前記オブジェクトの総数である構成オブジェクト数に応じて、再生するサウンド数を決定するサウンド数決定処理を行い、
    前記オブジェクトグループを構成する前記オブジェクトの種類毎の数の比率に基づく確率で、当該オブジェクトの種類毎に関連付けられた前記再生用サウンドが抽選されるように、当該再生用サウンドを前記サウンド数だけ抽選するサウンド抽選処理を行い、
    前記サウンド抽選処理により抽選された前記再生用サウンドを再生する再生処理を行い、
    前記構成オブジェクト取得処理、前記サウンド数決定処理、前記サウンド抽選処理、および前記再生処理を継続的に繰り返し行う、情報処理装置。
13. コンピュータを備える情報処理システムであって、
    前記コンピュータは、
    仮想空間に配置された少なくとも１つのオブジェクトにより構成されるオブジェクトグループを管理するグループ管理処理を行い、
    前記オブジェクトの種類毎に少なくとも１つが関連付けられた再生用サウンドを取得するサウンド取得処理を行い、
    前記オブジェクトグループを構成する前記オブジェクトの種類毎の数の情報を取得する構成オブジェクト取得処理を行い、
    前記オブジェクトグループを構成する前記オブジェクトの総数である構成オブジェクト数に応じて、再生するサウンド数を決定するサウンド数決定処理を行い、
    前記オブジェクトグループを構成する前記オブジェクトの種類毎の数の比率に基づく確率で、当該オブジェクトの種類毎に関連付けられた前記再生用サウンドが抽選されるように、当該再生用サウンドを前記サウンド数だけ抽選するサウンド抽選処理を行い、
    前記サウンド抽選処理により抽選された前記再生用サウンドを再生する再生処理を行い、
    前記構成オブジェクト取得処理、前記サウンド数決定処理、前記サウンド抽選処理、および前記再生処理を継続的に繰り返し行う、情報処理システム。
14. 情報処理装置のコンピュータに実行させる情報処理方法であって、
    前記コンピュータに、
    仮想空間に配置された少なくとも１つのオブジェクトにより構成されるオブジェクトグループを管理するグループ管理処理を行わせ、
    前記オブジェクトの種類毎に少なくとも１つが関連付けられた再生用サウンドを取得するサウンド取得処理を行わせ、
    前記オブジェクトグループを構成する前記オブジェクトの種類毎の数の情報を取得する構成オブジェクト取得処理を行わせ、
    前記オブジェクトグループを構成する前記オブジェクトの総数である構成オブジェクト数に応じて、再生するサウンド数を決定するサウンド数決定処理を行わせ、
    前記オブジェクトグループを構成する前記オブジェクトの種類毎の数の比率に基づく確率で、当該オブジェクトの種類毎に関連付けられた前記再生用サウンドが抽選されるように、当該再生用サウンドを前記サウンド数だけ抽選するサウンド抽選処理を行わせ、
    前記サウンド抽選処理により抽選された前記再生用サウンドを再生する再生処理を行わせ、
    前記構成オブジェクト取得処理、前記サウンド数決定処理、前記サウンド抽選処理、および前記再生処理を継続的に繰り返し行わせる、情報処理方法。

Images