リズムFPSとしての方向性を決定する

『BPM: BULLETS PER MINUTE』は射撃、リロード、ジャンプ、ドッジ（かわす）をすべてビートに乗せて行うリズムアクションFPSです。

私たちは作業を開始する前に以下の3つのデザインアプローチを検討しました。

1. 音符表 （例『ギターヒーロー』『ロックバンド』『Frets on Fire』）。各トラックにアタック、ドッジ、リロードのビートを定義するメタデータを入れます。このメタデータの情報が敵の行動を左右します。音符表がAIに何をするべきかを指示します。

長所: 洗練された流れに沿った経験となり、質の高いユーザ生成コンテンツが生まれる可能性があります。

短所: ゲーム1分あたりの制作コストが非常に高くなります。プレイの再現性が低いです。

2. プロシージャル音楽 （例『パラッパラッパー』『Wii Music』）。音楽はトラックセグメントで構成されます。トラックセグメントは動的で、アルゴリズムが次のトラックセグメントを選択して再生します。その後AIがトラックセグメントごとに特定のマーカーを攻撃します。

敵が16分音符に合わせてすばやく攻撃し、続くバックビートで敵がスネアのヒットに合わせて攻撃してくるドラムロールセグメントを想像してみてください。

長所: 動的で再現性があります。

短所: 音楽の質が低くなる可能性があります。歌という構造ではなくプレイヤーによって音楽が定義されるため、音楽的なストーリーが貧弱になります。

3. ビートのみ （例『クリプト・オブ・ネクロダンサー』）。AIは音楽のビートに合わせて動きますが、その動作はトラックの状態に依存しません。

長所: 動的で再現性があり、また音楽には旋律のストーリーがあるため、簡単にコンテンツを増やすことができ、ゲームのデザインが音楽の成果物に依存しません。

短所: 音楽をプレイヤー体験に合わせてカスタマイズできません。

私たちは少人数のチームでしたが、何時間もプレイできるかなり大きなゲームをつくりたかったため、「ビートのみ」のアプローチを採用しました。開発しながら自分たちも楽しめるよう、ローグライク構造にしました。ローグライクはレベルをランダムに生成してくれるため、プレイするたびに新鮮でゲーム開発の進捗を楽しめます。ローグライクではプレイの再現性が強く求められるため、音符表のアプローチでは『BPM』に必要な最大30時間ものゲームプレイが得られないことは分かっていました。

『BPM』では主にボスの倒すときの演出として、プロシージャル音楽をいくつか入れることに決めました。これはボスを倒した時にプレイヤーが操作できるクレッシェンドとして再生されます。

ゲームプレイの調整

『BPM』のゲームプレイは基本的に1分間に88ビート、4/4拍子で動くステップシーケンサーです。敵は数ビートの間に"攻撃"を演奏したいというリクエストを出します。具体的にはステップシーケンサーに対して問い合わせを行い、指定したビート時に攻撃すると、過剰な不協和音にならないかを確認します。

敵はステップシーケンサーに対して「2ビート後にプレイヤーを攻撃してプレイヤーにドッジ（回避）を強いたい」と伝えます。ステップシーケンサーは「Yes」または「No」と答えます。ステップシーケンサーの回答はそのビートで攻撃が多すぎないか、また指定されたビートを別の敵が独占していないかなどに基づいて判断されます。このように『BPM』のゲームプレイ全体は、このステップシーケンサーによって情報提供されています。

シーケンサーはプレイヤーのゲームプレイにも関わってきます。プレイヤーのアクションは1/2ビートごとにしか行えません。1/2ビートごとにプレイヤーは射撃やジャンプや魔法をかけることができます。ただしリロードやドッジや射撃や魔法など、どのアクションも1/2ビートにつき 1つしか 行えません。（ジャンプはいつでも自由にできますが、ビートに合わせてジャンプさせようとしたものの、うまくできませんでした。）

そういうわけで、トラック内のどこにビートが来るのかを確実に知ることが技術的に一番大きな課題でした。Unreal Engineの内部で解決策を実験しましたが、当時はオーディオクロックとゲームクロックを同期させることができませんでした。またトラック間をトランジションする際に、サンプルが欠如してポップ音が発生してしまうのは避けたいと考えました。

私たちがWwiseを選んだのは、3つの問題を解決してくれるからです。

1. トラックのトランジションがうまくいく。

2. 音楽がスラップして効果音が常に聞こえなければならないゲームをミキシングできる。

3. ビートが同期できる。

トランジションとエフェクト

ジョシュ・サリバン（Josh Sullivan）: 『BPM』のサウンドはすべて私が担当しました。私のサウンドづくりとミキシング手法はちょっと変わっています。映像制作の経験が10年以上あるので、『BPM』に入れる音をプログラムでミックスしてマッシュアップする段階になって私が使ったのはSony Vegas（動画編集ソフトウェア）で、実際のオーディオ編集スイートではありません。私は以前からVegasのことをSound Forge（ソニーのサウンド編集スイート）に動画のプレビューウィンドウをつけただけという感覚で使用していました。

幸いなことに『BPM』のサウンドトラックのテンポが88bpm（1分あたりのビート数）でした。ゲーム全体でテンポが一定だったおかげで、テンポを合わせる必要のあるオーディオシーケンスをすべて88bpmのクリックトラックに簡単にカットできました。例えば『BPM』の武器のリロードステージはどれもビートにぴったり合っています（『ベイビー・ドライバー』風に）。私はこれを達成するためにSony Vegasのタイムラインに実際にクリックトラックを入れ、この物理的なクリックトラックに合わせて各サウンドをカットしました。どのサウンドもその1種のテンポにぴったりついきます。ただし2種類以上のテンポがある場合はこの方式は通用しません。

音の準備ができたらそのままWwiseにインポートしてポジショニング情報を（必要に応じて）付与するだけです。次に必要であればサウンドインスタンスの制限を設定します。例えば四分音符ごとに発射されるミニガンは、まさに制限が必要な例です。この発射速度ではミックスが濁ってしまうことがあり、ミニガンのショット音は一度に1つだけに制限するのが得策です。さらにGeneral Settings（ボイス、ピッチなど）を調整します。最後にそれぞれの出力バスにサウンドを設定します。特筆すべきは銃声のようなサウンドで、1丁の銃に対して少なくとも4つの固有のサウンドを出しています。そして、それらをすべてRandom Containerに入れることで、プレイヤーが繰り返しだと無意識に感じてしまわないようにしています。

ここまで終わればWwiseでオーディオと紐づくイベントを作成するだけです。イベントについてはあまり複雑なことをしませんでした。1つやったことは、イベントで新しいサウンドをスタートさせる前に前のサウンドを停止させることです。敵のざわめき（リズムに合わせたうめき声や唸り声）はその一例です。敵の痛みのWwise Eventをトリガーすると「ouch（痛い）」のRandom Containerが再生されるだけでなく、同時に敵のざわめき声も停止されます。

音楽の面ではWwiseのMusic Switch ContainerやMusic Playlist Containerを使って比較的簡単に1つの音楽ピースから別の音楽ピースにトランジションでき、時間設定のおかげでビートに合わせて同期させることができました。

ところで特定の音楽の時は、リズムをあえてほかの音楽に合わないようにしている場面があり、それがボスのフィニッシャーです。ボスを倒す時はテンポよく再生されない中でボスを仕留めることができます。音符のショットは1つずつ自分のタイミングで発射でき、次のショットを発射するまでそれぞれの音符が無限にループしなければならないのです。厳密には「音楽」ですがWwiseのイベントとして実装しやすいよう、私は「サウンド」として扱いました。

リズムアクションゲームのミキシング作業

サム・ホートン（Sam Houghton）: プレイヤーを強烈なロックオーケストラのバンドリーダーになった気にさせることが、『BPM』をミキシングした私の一番の目標でした。ミックスの中心となる楽器が武器で、プレイヤーが求めるのはゲームの流れにのって大連発をしたときの強烈な爽快感です。逆にプレイヤーのショットやリロード、アビリティのタイミングが悪ければ、ビートに合わずサウンドが全く再生されないので空しく残念なサウンドになります。

音楽は私がジョー・コリンソン（Joe Collinson）と共に作曲し、ショットなどのサウンドが入る余地を音楽アレンジの中に残しました。するとオリジナルサウンドトラック（OST）は最高だけど、ゲーム中にガンショットが加わるとさらによくなるというコメントがネットで多く寄せられたのです。それを読んだ時はとても興奮して、プレイヤーに意図が通じたんだと思いました。結局のところ、ゲームのサウンドトラックの目的はまさしくゲームプレイをサポートすることです。この面がほかのゲームジャンルよりも『BPM』で目立っているだけです。

初期の頃、プレイヤーがリズムに合わせてアクションを起こしたときに音楽チャンネルをダッキングさせて試行錯誤しましたが、わずかにダッキングしたところで満足感が高まるわけでもなく、むしろゲームのパワーが少し薄れました。私がWwiseで行ったのはところどころで音量の微調整をするくらいで、ほかの音が音楽の中でクリアにパンチが効いて聞こえるようにしただけです。ジョシュ・サリバンがゲームのすべての音をつくってくれて、それが素晴らしい出来栄えだったので、私のミキシング作業は楽でした。 

ビートの同期

デビッド・ジョーンズ（David Jones）: ゲームのクロックをビートに同期させる時に、私は『ボーダーランズ』の解決法のようにWwiseに修正を加えてMIDIコールをのっとりゲームロジックに割り込むのが最適の実装ではないかと考えました。ビートが終わるたびにその瞬間の入力状態を要求するのです。

Wwiseでこのビートイベントを呼び出すたびに、コントローラからの入力をほぼ瞬時にポーリングできるのは完璧なソリューションです。まるでサンプルベースのアプローチです。最大限の精度を実現するためにプレイヤーの入力とオーディオを緊密に連携させた実装にして、プレイヤーの入力が遅いのか早いのかをミリ秒（ms）単位で判断するのです。音楽とリズムがあまりにもズレている入力は棄却します。ところが私たちのチーム人数ではこの解決法は無理でした。Unreal Engineの入力システム全体に介入し、Wwiseの変更も必要なため、フルタイムのオーディオプログラマーが1人必要となるような仕事内容です。そこで別のアプローチで進めることにしました。

気の利いたハック

私たちのソリューションはとても単純で軽量です。ミュージックイベントにコールバックを登録して EAkCallbackType::MusicSyncBeat を探すのです。このイベントがMusic Switch Containerからくるたびに、ゲームクロックと暗黙のうちに進捗するミュージックトラックの差分が分かります。差分が10ms以上であればゲームクロックの再調整を行った上で、すべての関連アクターに対してイベントを呼び出します。

この単純なキャリブレーション方法を選んだのは、今回のゲームプレイでこれ以上手の込んだ調整が必要なかったからです。敵の動きとビートの誤差は10ms未満に抑えられ、私たちのリズムテストの基準よりもはるかに小さいです。

一方プレイヤーからの入力に関しては、ほかにも考慮すべきエラーがあります。プレイヤーエラーの幅は:

クロックキャリブレーション10ms ＋ フレームタイム [frametime]ms ＋ deferred rendererの使用で追加[frametime]ms ＋ 入力デバイスで [?] ms ＋ コンソール処理に [?] ms ＋ テレビまたはオーディオの出力処理に [?] ms。

使うシステムによってかなりの誤差が生じる可能性があります。誤差はユーザによって大幅に違うことが分かっていました。しかしもっと重大な問題が潜んでいて、それはリズムFPSに「Cursed Problem（呪われた問題）」があることです。

Riot Gamesのアレックス・ジャフィ（Alex Jaffe）氏が2019年GDCの講演で、「Cursed Problem」とはコアプレイヤーの約束事の対立に根ざした、解決不可能なデザイン上の問題と定義しました。『BPM』ではプレイヤーに「ビートに合わせて撃つこと」と「引き金を引くと弾が発射される」の2つを約束していて、これらは相反するものです。この問題は「ギブアップすることで勝つ」しか解決方法がありません。

『ギターヒーロー』のようにビートに合わせてプレイするゲームでは、プレイヤーがコントローラのキャリブレーションを行うとレイテンシが設定され、このレイテンシを使ってプレイヤーの入力がオフセットされます。音符と因果関係のあるエフェクトはないため、レイテンシを考慮して音符をテストできます。プレイヤーが過去にリズムの入力を達成したかどうかをゲームがテストし、動画のレイテンシを補正します。ゲームは音符を押すべきタイミング、音符を押したタイミングと、テレビのレイテンシを把握しています。そこでゲームは過去を振り返り、プレイヤーが 現在の時間からレイテンシ時間を引いた時間 の許容範囲内に入っていたかどうかを確認します。ここを理解するのは難しいかもしれません。『ギターヒーロー』ではこのような理由のため、音符が線の下に消えた時に、線を超えたのに正しく弾かれたようにみえることがあります。プレイヤーはテレビ画面のレイテンシを、リアルタイムで目撃するわけです。一方FPSでは瞬間ごとに狙いを定めるため、この方法は使えません。

『BPM』はユーザのレイテンシを80ms未満と想定します。これ以上のレイテンシのユーザは、起動時のキャリブレーションシーケンスで検知されて自動リズムが有効になります。自動リズム機能が有効な時にプレイヤーのショットが入力されると、次のビートが発生するまでその入力をホールドします。ユーザのレイテンシが80ms未満であれば、速めに撃たれた弾を次のビートまで遅延させてから発射させ、遅めに撃たれた弾はすぐに発射させます。

『BPM』には、プレイヤーのフィーリングを優先して、一部のタイミングが下手なアクションを許してくれる魔術もたくさんあります。タイミングの許容範囲を定義するために、さまざまなロジックが仕込まれています。そのほとんどは、どのような入力構成でも問題なくプレイできるようにするためのものです。厳密にビートに合うリズムゲームよりも、壮大なロックオペラのシューティングゲームを体験してもらいたかったのです。

最終的に『BPM』が成功したのは音楽とゲームプレイがしっかり統合されていたからで、Wwiseはスピードとコントロールを備えた『BPM』の実現に貢献しました。