ゲームオーディオに携わり、小さなゲームプロジェクトに関わった人なら誰でも、この議論をしたことがあるはずです...。

「Wwiseみたいなミドルウェアは、自分達のニーズに、ちょっとレベルが高すぎでは？ゲームは小さいし、予算は厳しいし。サウンドエンジンが、（Uで始まる適当なゲームエンジン名をここに挿入）にネーティブでビルドインされているから、単純にそれを使えばいいのでは？サウンドエフェクトを何種類かと、ちょっとしたループミュージックを使うだけだから、充分なはずだよね?!」

ごもっともな意見です。一般的なゲームエンジンに最初から入っているネーティブのサウンドエンジンも最近は高機能になり、少人数のチームでは、確かに1つのツールに集約されていた方が作業手順にしろコストにしろ、優位な点が多いと思います。ただ同時に、私たちは、サウンドデザイナーやコンポーザーやオーディオインテグレーターとして、ほかでは置き換えられないオーディオミドルウェアの利点についても、よく分かっているわけです。Wwiseのようなツールがあると作業が速くなるだけでなく、柔軟性や拡張性が向上します。ゲームのオーディオ担当者以外にも小さいゲームプロジェクトにWwiseを取り入れるメリットを納得してもらうには、どうすればいいでしょう？あなたは、相手を説得するための知識を増やしたいオーディオエンジニアかもしれませんし、Wwiseやオーディオミドルウェアを使ったことがなくて詳しく知りたいと考えているのかもしれませんが、この記事が何かのお役に立つかもしれません。それでは、特に小さいゲームを念頭に、Wwiseのメリットを5つ紹介します。

1: コーダー達に自由を！

今回、これが一番強調したい点であり、Wwiseがネーティブのオーディオエンジンに勝る理由を1つに絞るとしたら、これです。Wwiseをコーダーがインプリするのは簡単で、Wwiseを使えば、オーディオエンジニアの希望通りの音をつくるために必要なコーダーの作業が、グッと減ります。ゲームオーディオの実装は、技術的や芸術的な観点で複雑ですが、Wwiseはそれをコーダーの担当から外し、オーディオエンジニアが完全に自分で制御できるようにします。コーダーは、大幅に節約できた時間をほかのタスクに費やせます。

この記事でこれから紹介するほかの利点については、必ず「それはゲームエンジンにスクリプトで追加できるよ」と反論される可能性があります。確かに、優れたプログラミング能力と暇さえあれば、何だって可能です。ところが、小さいプロジェクトチームの場合は普通、時間こそコーダーたちが持て余していないものなのです。効率性が必要不可欠で、Wwiseのようなツールを使えば、リソースを確実に効果的に配分できます。

2: 未来に備えたオーディオ実装

Wwise内のプロジェクト構成はゲームエンジンに見えるものとは、独立しています。つまり、水面下のWwiseエディター内で自由に構成されている部分が大きいということです。イベント名やパラメータ名といった肝心な部分を変えなければ、オーディオエンジニアは自由に、自分の好きなプロジェクト構成をまとめ（さらに便利なことに、まとめなおすこともできる）、ゲームエンジン側は何も変えなくていいのです。なにをやっても「うまく動く」のです（もちろんWwiseプロジェクトを最初に正しく設定する必要あり！）。

ここでの利点は、Wwiseプロジェクト自体が、ゲームと共に自然に成長し、コードの変更が一切不要だということです。オーディオ側のニーズの範囲が広がり複雑になってきた場合は、それに合わせてオーディオ内部を自由に組み替えたり再編したりできるので、わざわざコーダーに連絡する必要もありません。これによって複数の開発方式にも対応できるので、非常に便利です。もし開発チームが、最初に手早くまとめてとりあえずの形をつくり、そこから反復を繰り返して洗練させていくようなやり方を好めば、まずWwiseプロジェクトをベーシックな設定でスタートさせて、ゲームの追加機能ができあがってきてから再編できます。逆に既定デザインに厳密に従って作業を進めるチームの場合は、Wwiseプロジェクトの全体構成を事前に設定してゲームに予定される機能をすべて取り込めるようにしておけば、あとから変更点があっても、簡単に整理しなおせます。

Wwiseのプロジェクト構成は水面下で自由に設定でき、ゲームエンジンとサウンドバンクの関係性に全く影響しない。

3: ゲームと共に進める開発

オーディオエンジニアがゲームエンジン内で、ゲームのサウンド開発を行うと、ゲームの実際の機能によってオーディオがブロックされてしまうことがあります。また、未完成の機能や不安定な機能に対して音を実装する必要が出てくることもあります。オーディオ開発のスケジュールをゲームの状況に合わせて調整するのが段々と複雑になり、本来は設計やアセット制作にかけたい貴重な時間を奪われてしまいます。

ゲーム開発と並行してWwise上で作業できれば、オーディオエンジニアはゲームの進捗状況とは独立してオーディオの実装をセットアップして完全にテストできます。必要に応じてオーディオエンジニアがゲーム開発より先に作業を進めて、まずWwise環境内でうまく動くように整えることも可能です。準備ができ次第Wwiseイベントをゲームエンジン内からトリガーすれば、サウンドはすぐに出ます。これは、ゲームの機能を実装前に設計する場合や、技術的な問題で開発が遅れたときに、非常に助かります。オーディオ開発パイプラインだけ切り離して動かし、効率的に進められます。

4: 速い成果

Wwiseは、オーディオエンジニアが速く仕事をできるように、様々な機能を提供しています。例えば、

• アンビエントベッド用に、シームレスループの準備ができていないサウンドがありますか？そのサンプルに、クロスフェードするループポイントをSource Editorで追加するだけで大丈夫。

• 複雑なダイアログツリーを設定できたけれど、そこにもう1言語を追加することになりましたか？ローカライズした新しいボイスファイルのファイル名が必ず一致するようにして、あとはドラッグして入れてLocalise Languagesを選択するだけ。これで完了。

• へんなエラーが発生して、裏で何がおきているのかを確認したいですか？Profilerをチェックして、入ってくるイベントコールをすべて見渡せる概要     を表示させれば、何が起きているのかが分かります。

• アセットの圧縮要件が異なる別のプラットフォーム用に、オーディオ実装の別バージョンをビルドする必要がでてきましたか？Soundbankや圧縮設定を活用すれば、そんなの簡単です。

• ゲームが業界標準のラウンドネス標準に準拠しているか、検査する必要がありますか？Loudness Meterの既定カラーガイドを使えば、ターゲットLUFSを表示できます。

• 大量のイベントを、命名規則     に沿った形で作成したい場合は？アクション名のプレフィックスやサフィックスをProject Settingsで設定して、すべてのエンティティ用に、イベントを一括作成できます。

• エンティティ名の一括変更や、設定の一括変更を行うには？すべて、Batch RenameとMulti-Editorを使います。

使用例を挙げれば、きりがありません。Wwiseだけの機能とは限らず、多くはスクリプトやサードパーティのツールを使えばゲームエンジンで直接達成できます。ただ、こういった便利機能のおかげで節約できる時間を全部合わせると、オーディオエンジニアが、ゲームのサウンドを最高にするために使える時間が増えます。

Event Creation設定は、複数のイベントを、一定のネーミング規則に従って一括で素早く作成するのに非常に便利。

5: 制限あるアセットで、効果を最大化

少ないものを使って多くを実現することは、小さいゲームプロジェクトの要となる大事な考え方です。Wwiseには、オーディオエンジニアが作成した個々のアセットを最大限に使いこなすための便利な機能がいくつかあります。例えば、

• Randomisation機能を使えば、単一サウンドのアセットで微妙なバリエーションを出せます。1つのサンプルの可能性を引き出しながら、反復を隠したいときに向いています。

• 同じアセットを、複数のイベントからトリガーできます。基本的なサウンドを集めて、様々な配列で重ねたり同時トリガーしたりすれば、バリエーションが増えます。

• Wwiseの総合的なミュージックシステムを活用すれば、ゲーム内のプレイヤーの行動に反応する、複数レイヤーから成るダイナミックなサウンドトラックがつくれます。基本的な、重ね合わが可能なミュージックループを、いくつか用意すれば、「繰り返し」とも「想定内」とも感じさせないダイナミックなミュージックスコアを達成できます。

• Wwiseには基本的なシンセシス機能が備わっているので、アンビエントノイズベッドや、風や、UIの合成音などを簡単にセットアップしたり、サンプルアセットのバリエーションとインパクトを拡大するために重みを加えたりすることもできます。

Wwiseのミュージックシステムはとても柔軟で、ベーシックなミュージックループをいくつか使うだけで、状況に応じて変化する複雑なミュージックスコアをつくれる。

まとめると…

Wwiseがもたらすプロダクションの効率性も、ワークフローの柔軟性も、オーディオエンジニアの時間節約という観点だけでも、小さなゲームプロジェクトにとって間違いなく素晴らしい追加ツールとなるはずです。Wwiseを導入すると、コーダーにとってはオーディオパイプラインが簡略化され、オーディオエンジニアにとっては必要な制御機能が全面的にそろい、将来的に拡張可能な方式でオーディオを実装できます。