真砂楼の開発手法について サウンド編
お久しぶりです。
一年ぶりの記事になりますが、なんとこの一年の間に自分の携わったゲーム「真砂楼」がリリースされました。
真砂楼の制作は趣味で集まった数人で行われたので、開発内容についてはほぼ公開することができます。
そこで、このブログで真砂楼の開発について紹介する事にしました。
今回はサウンド編ということで、真砂楼のサウンドを担当した自分のワークフロー等を解説します。
UE4でのサウンド実装をどのように進めていったのか、がメインの話です。
真砂楼とは
Steam：
公式サイト：
dorsalfingamestudio.wixsite.com
Steamで2021年3月26日から発売中の3Dホラーゲームです。
このゲームの為に集まった数名(DorsalFin Studioと名乗っています)で制作しました。
製作期間は去年の頭から1年と少し。(自分は3月から加わったのでほぼ1年)
メンバー全員が仕事の合間に趣味として開発作業を行いました。
外部のパブリッシャーは無く、およそ一般的なインディゲームかと思います。
オーディオデザイン担当として
真砂楼の開発には当初からプログラム担当と背景担当が決まっていましたが、サウンド担当がいないということで自分がその辺りを手伝わせてもらう流れで開発に参加させてもらいました。
とはいえ自分にはサウンドデザイナーとしての業務経験等は無く、趣味でゲーム用の音声ファイルを差し替えて楽しんでいる程度です。まずはゲームで必要とされる音声を用意する作業から始め、プログラム担当と音声の鳴らし方について打ち合わせしつつ、UE4標準の音声機能でやれる事をやる、という流れでサウンド関連の構想を進めていきました。
上記の流れは特に支障なく事が運び、結論としてUE4の標準機能でサウンド関連の最低限やりたいことは全て出来る、とわかりました。ここに至るまでが割と早く、まだ開発初期だったのでなにか一つ挑戦したいと欲が出てしまい、以前から興味があった立体音響用のプラグインを導入する事にしました。
結果としてSteam Audio(https://valvesoftware.github.io/steam-audio/)の導入を決定し、Steam Audio前提のサウンド関連ワークフローを改めて検証し、なんとか無事にリリース出来ました。(実は紆余曲折あり、後述します。)
このように、自分が携わった範囲はサウンドを用意するだけでなく、プラグインの選定及びそれを前提とした再生制御やワークフローの決定にまで関わったので、今回はサウンドデザイナーではなくオーディオデザイナーと名乗っています。音響業界の事は全く知らないので、素人の言葉遊びとして大目に見てやってください。
真砂楼のオーディオデザイン
真砂楼のサウンド制作を行うにあたって、まずは以下の2点から考えました。
- どんな音が必要か
- どんな鳴らし方をするのか
1に関しては、プロジェクトの方向性が
・日本を廃旅館を題材にした3Dホラーゲーム
・グラフィックはフォトリアリスティック
と早期に決まっていたので、
「出来る限りリアルで没入感の高い3Dサウンド」を目指すことにしました。
2は1を基に考え、可能であれば旅館という閉鎖空間を再現した鳴らし方を目指しました。その結果として、前述の立体音響プラグイン「Steam Audio」を採用しています。
Steam Audioによって以下の機能が可能になっています。
- 周囲の環境に応じたリバーブ
- 遮蔽物の材質に応じたオクルージョン
真砂楼では前者の恩恵を特に受けています。(狭く細長い通路と広く奥行きのある部屋でリバーブが違う等)
なお、今回はインタラクティブなサウンドは制作期間の都合でほとんど考慮せず、
が主な3Dサウンドとなっています。
なお、プロジェクトのUEバージョンは4.25.4です。
開発当初は確か4.24だったと思うのですが、サウンドに影響するアップデートがあった為、4.25に引き上げました。
UE4.25から、シーケンサー上で各アクタにサウンドをバインド出来るようになっており、これがワークフロー上とても助かりました。
この機能が無いと、アクタの位置からサウンドを再生するのに一工夫する必要があります。思いつく限りだと、BPに再生用のイベントを用意しておき、再生したいタイミングでイベントトラックからトリガーする等でしょうか。
UI用の2DサウンドやBGMに関しては特筆する点はありません。
基本的なワークフロー
今回のサウンド実装ワークフローは、個別のサウンド実装と、Steam Audioによる空間音響の調整の2つからなります。
個別のサウンド実装
が基本的なサウンド実装のワークフローになります。
真砂楼では、BPから直にサウンドキューを指定するのではなく、サウンドキューをID管理するデータテーブルに登録する方法を採っています。
これにより、4の工程ではデータテーブルにIDとサウンドキューを登録し、後はサウンドを再生したいギミック等にID入力する作業となります。
この方法はプログラム担当の方から提案してもらいました。
BPとサウンドキューの依存関係が無くなり、サウンドキューアセットを何時でも自由に編集できるメリットがあります。(後からサウンドキューを作り直したりしても、データテーブルの指定を変えるだけで済むのでBPに影響が無い)
但し、BPとサウンドキューに参照関係が無くなるので、サウンドがどこで使用されているか等の検索性が著しく下がります。この点を考慮した上で、プロジェクトの規模や情報管理でフォロー出来るかを基に判断し、今回はこの方法で行く事にしました。
Steam Audioによる空間音響の調整
がSteam Audio用の作業になります。(1~3はこの順番でなくとも可)
なお、4はSteam Audioの処理をベイクデータを基に行う場合の作業なので、リアルタイム処理にする場合は必要ありません。
このワークフローは基本的にサウンドの用意が出来てから空間音響での聞こえ方を調整する作業になります。
ベイクはあくまでシーンデータに対するものなので、サウンドを追加する度にベイクをし直す必要はありません。
個別のサウンドに対して1つずつ設定する作業ではないのでそこまでの負担にはならないのですが、2だけは完全に個別の作業となります。
スタティックメッシュアクタに対してPhonon Materialコンポーネントを追加し、そのコンポーネントで材質のプリセットを設定します。
この作業に関してはEditor Utilityで自動化出来るだろうと踏んでいたのですが、UE4.25.4に付属しているSteam AudioプラグインではBPに変数が公開されていなかった為出来ませんでした。
せめてコンポーネントの自動追加だけでも・・・と思ったのですが、これもUE4.26からBPに関数が用意されていたので、4.25で固定した今回は諦める事にしました。
Steam Audioの試行と採用
Steam Audioを採用にするにあたっては以下の点を判断基準としました。
- プラグインを拡張する必要が無い
- PIE(プレイインエディタ)からShippingパッケージまで全て同等の挙動で確認出来る(偶に各動作モードで挙動が違う事がある為)
- 調整の為に手作業で時間をかけたりしない
これらを基準に1ヶ月ほどSteam Audioの各機能を試した結果、1と2は特に問題ありませんでした。
下記ドキュメントの通りに全ての機能にアクセス出来ますし、Shippingパッケージでも想定通り動作していました。
Steam Audio Unreal Engine 4 Plugin
但し、3に関しては一部懸念があり、上述の通り各アクタに材質の設定をする必要がありました。
これは自動化出来ると踏んだのですが、結果として手作業で設定する事になり、終盤になって割と重たい作業になってしまいました。ここは反省点です。
ちなみに、Steam AudioではSound Attenuationアセットに各種設定用のアセットを紐付ける設計になっており、サウンドの聞こえ方をSound Attenuationアセットに依存する運用にしておけば複雑にならないように出来ています。
真砂楼では最終的に10種類程度のSound Attenuationアセットを用意し、それを各サウンドキューから指定しています。
また、オーディオボリュームを使用する事は無いので、レベル上で調整作業をする事は(材質設定を除いて)ほぼありません。
この点は作業量から考えて魅力的でした。
結果と課題
作業量とスケジュール
上述の開発ワークフローで約1年間の開発期間を経て、なんとかリリースまでに一通りのサウンドを実装することが出来ました。
プレイヤーの足音・ギミックの効果音・環境音・UIサウンド・ラジオ音声(これは希望者の肉声を収録して加工しました)等があり、Waveファイルの数は約300、サウンドキューの数は約100となりました。
これらをリバーブやオクルージョンのかかり方を考慮しつつ調整するので、リリース前の数ヶ月は割と大変でした。
一応スケジュールに余裕は持っていたのですが、最後のSteam Audioのベイクでトラブルが発生し、最終ベイクデータを基にした調整にあまり余裕が無かったのが想定外でした。
Steam Audio用のベイクは定期的に行っていたのですが、プロジェクト後半でシーンデータの複雑さが一気に増していき、今年に入った頃にはベイク時間が1時間を超え、データは単体で100MBを超えている状態でした。
それに伴った諸問題も発生しており、解決するために一工夫したのでそちらについても後ほど解説できればと思います。
Steam Audio採用の結果
目標としていた、「出来る限りリアルで没入感の高い3Dサウンド」に関しては概ね自分の想像していたものに仕上がりました。
Steam Audioによるリバーブに関してはもう少し空間に応じた違いを出せるかと思っていたのですが、シーンに似通った場所が多いので一部のみとなりました。
なお、オクルージョンについては当初はもっと複雑な機能だと勘違いしており、直接の遮蔽だけでなく反射による間接的な伝搬と組み合わせたものだと思っていたのですが、実際には直接遮蔽だけだったのであまり活用できませんでした。
この点は材質の設定とも関わってくるので、後ほど詳しく説明する予定です。
Steam Audioの検証不足から若干の作業量の増加は出たものの、問題無い範囲に収まり、その分のクオリティを出すことには成功したと見ています。
総評
個別のサウンドに関しては一部満足いかなかった出来のものもありますが、予め開発期間と予算の都合でそうなるものと予想していた範疇でした。
作業量が想定を超えてしまい諸々の対応が後手に回ってしまう、と言ったことも無かったので、初めて開発の最初から最後まで携わった身としては想定通りに上手くコントロール出来た方かと思います。
最後に
開発期間1年・プライベートの時間で作業、という条件の中でここまで出来たのでとても良い経験になりました。
ただ、インタラクティブサウンドの要素に関しては当初からほぼ切り捨ててしまったので、恐怖を煽るサウンド演出やゲーム性に関わるサウンド実装はほとんど出来ませんでした。
今後はその制作手法についても考えていきたいです。
