UnityでWwiseを使う

LudamDare44（ゲームジャム）にてWwiseを使用したので、

自分の確認のためにも書いていきます。

完成したゲームはこちら

https://ldjam.com/events/ludum-dare/44/over-there

ゲーム自体は簡単なシューティングゲームで、

敵に弾を発射して倒し、自機を飛ばすためのアイテムを取り続けるという流れです。

 Wwiseを用いることによって何が変わったか

まずプロジェクトのサウンド面における実装速度が全く異なりました。

通常であれば効果音一つとってもプログラマーさんが音が鳴るためのプログラムを書き実際に動作させ、サウンド担当が確認を行い異なっていた場合はどのように異なっているか伝え、音声ファイルに問題があればサウンド担当が修正しそれを再度プログラマーさんが修正する（以下納得いくまで無限ループ）となりますが、wwiseを使用すると音を鳴らすタイミングそのものはプログラマーさんが用意するものの細かなタイミングや音量、途中変更等についてはサウンド担当が一人で行えるので、実装速度がかなり向上しました。(サウンド担当のみで実装可能な部分も劇的に増えます)

wwise不使用

[プログラム担当]→[サウンド担当]→[プログラム担当]→[サウンド担当]→無限ループ

 wwise仕様

[プログラム担当]→[サウンド担当]→ゴール！

またサウンド部分のみUnity外での作業となるので誰かがSceneやPrefabs上で作業していてもコンフリクトせず編集できるため時間短縮できた場面も多くみられました。

WwiseをUnityで使用した際のトラブルとか

wwiseを用いて鳴らしているコンポーネント（AK Event等）はwwise側のプロジェクトから読み込むためwwiseを導入していない人からはコンポーネントにアタッチされているEventを編集できない。

wwiseを導入していない人でも音が鳴るようにするにはひと手間かかる

また初期段階にてSoundBankが空の場合Unity側がエラーを吐く（実行することは可能なので支障はない…多分）

日本語のリファレンスが少ない。

以上の事柄でトラブルが発生しサウンドミドルウェアを使うにあたっての利点(時間短縮)が少ないゲームジャムになってしまいました。

これらトラブルを解決また発見するためにGit経由でwwise自身のプロジェクトデータを共有し、プログラマーさんのPCにもwwiseを入れてもらって少しづつ解決することにしましたが、wwise自身は共有することに対応した挙動をする（ファイルの更新があるとリロードします）ものの、Wwise Unity Integration（wwiseとUnityを接続するアセット）は対応しておらず、PC内のUnityプロジェクトと結び付けられてるwwiseプロジェクトへのパスが他人と異なっているとwwise関係のUnity内のコンポーネントを編集できない事態に陥ってしまう事になりwwiseを使ってUnityのプロジェクトを進行する際はこれらの事柄を事前に防ぎながら行う必要がありました。

恐らくではありますが、Unityのプロジェクト内にwwiseのプロジェクトを入れることにより解決しそうではありますが、要調査…

以上問題も多く残りましたが積極的に使って損のないツールだとは思いますので、下準備さえしっかり整えれば爆発的なパフォーマンスが得られそうです。（小規模でも大規模でも）

次は実際に使用した機能を書いていこうかと思います。