Wwise 2022.1 Unrealインテグレーションについて
このバージョンはWwiseのUnrealインテグレーションにとって大きなマイルストーンです。Unreal Engine 5がエンジンを新たな領域へと導いたように、AudiokineticのWwise Unrealインテグレーションはこれら2つのツールの連携による可能性をさらに広げます。
変更の内容は1年以上にわたる懸命な開発作業と、WwiseとUnrealで作業をする開発者たちを交えた多くの議論を基に発展しました。過去数年の最適化の積み重ねや機能の追加を通して多くの教訓を得てきました。すべてのワークフローに対応し、すべてのゲーム要件を満たしカスタマイズせずに使えることが私たちの野心的なゴールでした。このゴールに向けて今回のリリースで大きな前進となることを、以下のセクションでご紹介します。私たちはWwiseを使う上での喜び、難しさ、不満などを共有してくださったユーザのみなさまに大変感謝しております。コミュニティのみなさまの声は私たちがプライオリティを判断し、より多くの方々のニーズに合うインテグレーションをつくる上でのヒントとなりました。
変更内容
プライオリティ
Wwiseインテグレーションの基盤となるのが、開発エンジンのネイティブなパーツとしてサウンドエンジンを公開するという考えです。Wwiseのコードはさまざまな製品で斬新なアイデアが日々展開されている中、オーディオアセットの開発、パッケージ化、そして再生を効率的に行う上で今では極めて重要となっています。新技術が導入され、開発されるプロジェクトが驚異的なサイズに拡大するにつれ、Wwise Unrealインテグレーションのプライオリティは最初のリリース以来変化してきました。VRへの対応といった新たな機能要件から、ワークフローをEvent-Based Packaging方式に移行させるようなプロジェクト構造のパラダイムシフトに至るまで、Wwiseはリリースのたびに前のバージョンから躍進してきました。Wwise 2022.1で私たちは改めてユーザにとって何が本当に重要なのかを考える時間を取り、どうすればWwiseのインテグレーションを「互換性」や「機能性」の追加を超えた観点で改善できるのかを検討しました。このようなプライオリティの考察を経て、今回のコードベースに関する重要な発見が複数ありました。
安定性：External SourcesとEvent-Based Packaging
インテグレーションの最初の改善点として、必ずしもすべての開発者にとって重要でない複雑なワークフローを排除しました。これらのワークフローの多くは安定性上の重大な問題を引き起こし、同じくらい大切なほかの開発ワークフローと干渉するものもあります。
そのわかりやすい例がExternal Sourcesシステムです。ここ数年間あらゆるプロダクトで活用できる1つのシステムを実装しようと試み、1つまたは複数のメディアファイルを1つまたは複数のExternal Sources（外部ソース）に接続するためのすべての可能な方法を追加しようとしてきました。アセットが制御されたライフタイムを有することを可能としたほか、そのようなアセットのパッケージ処理をシステム内で行えるようにしました。
External Sourcesの使い方は、Wwiseユーザが作成するプロダクトの数と同じだけあるというのが現実です。これが実はカスタムシステムであり、開発者やプロジェクトのニーズによって扱われ方が異なるということを私たちは発見しました。提供されたままのシステムに不満のない開発者もいますが、不要に複雑すぎて実装に際してバグを追跡しにくくしていると感じる人が多くいました。そして対策として多くの開発者がこの必須コードを積極的に改変して自分の具体的なケースに合わせています。
Event-Based Packagingも複雑性の拡大の1例です。2019.2でリリースされたこのシステムはその後も成長を続け、今のかたちにたどり着く頃にはまるでUnreal EngineとWwise Authoringが争っているようでした。2019.2から2021.1にかけてこの機能の開発のおかげで安定性を得ることができましたが、このシステムは私たちが意図した以上に複雑です。Event-Based Packagingをワークフローに取り入れた開発者の多くは成功して実装に満足していますが、このシステムの融通の利かない面によってワークフローが悪化したチームもあります。開発するゲームと同じ数だけアセット管理のアプローチがあるということを私たちは経験で学び、これはWwise 2019.2時点のEvent-Based Packagingの否定しがたい結果です。Wwiseは常に採用してくれたすべてのプロジェクトをサポートできる、シンプルでよく書かれたコードを適用することを目指してきました。ところがEvent-Based Packagingは複雑すぎるコードに進展し、そのすべての側面をすべてのプラットフォームでテストすることは不可能でした。さらに悪いことにUnreal Engineの可能性が実に無限大で多様で複雑であるため、私たちのシステムに作り込まれた自由度が災いし、特定のアクショングループがシステム全体を崩壊させるようなシナリオが発生しかねません。あまりにも複雑過ぎるため、いざ開発者が問題に遭遇した時はAudiokineticのサポートに頼るしか選択肢がないという事態も出てきました。
しかし「イベント1つに対してバンク1つ」の確約はアセット管理における真のゲームチェンジャーとなり、現代的で複雑なプロダクトを開発する上で必要なステップであると私たちは確信し続けます。Event-Based Packagingの導入で発生した諸問題をすぐにすべて解消できないと判明したため、Wwise 2022.1ではワークフローの大半に対応できるソリューションを提供するとともに、アセット管理ソリューションを開発者が移行し拡張できるよう、特別な注意を払いました。
その結果：
External Sourcesを任意としました。インテグレーションデモの一部としてExternal Sourcesの基本的な実装を提供していますが、開発者が自分のニーズに合わせて独自のExternal Sourcesバージョンを実装できるようになりました。発見の可能性、パッケージされた情報、メディアの発見、パッケージなどが含まれます。
レガシーワークフローとEvent-Based Packagingのワークフローを統合しました。開発者からのフィードバックと私たちの経験に基づき、両者ワークフローの最もよい部分を統合し、より現代的でまとまったWwise Unity Addressablesパッケージワークフローも統合しました。衝突する複数のシステムをサポートする代わりに、拡張可能な1つのシステムですすめることができます。
拡張性とコードのレジビリティ（Legibility）
歴史的に見るとWwise UnrealインテグレーションはWwiseサウンドエンジンをUnrealプロジェクトにプラグインする方法の1例としてはじまりました。次にUnrealインテグレーションで提供しはじめたのは、Unreal Engineでファイルをゲームと共にパッケージングする際の制限に対応するための、デフォルトワークフローです（Wwise 2019.2やWwise 2021.1で「レガシーワークフロー」と呼ばれているものです）。
Wwise 2019.2までのインテグレーションコードは、以下4つの部分に分けて定義することができます:
- Wwiseサウンドエンジン
- Unreal Engine
- Wwise Unrealインテグレーション
- ゲームコード
Wwise Unrealインテグレーションコードがゲームのインテグレーションや予想される動作と合わない場合、答えは常に「提供しているコードは1例でしかないため、自分で直せます」でした。部分的に複雑な箇所が潜んでいることもありましたが、コードは比較的シンプルで理解しやすいと考えられていました。
Wwise 2019.2でEvent-Based Packagingが導入されてからはWwise Unrealインテグレーションコードの複雑性が飛躍的に高まりました。例えばUnreal Editorで実行する各種処理、Wwise Authoringへのネットワーク経由の接続、数々のワークフロー、ワークフローの複雑性、メモリ管理、アセットの管理と取り扱い、アセットのコピー、移行の細かい手順など、WwiseをUnrealにインテグレートする「だけ」の作業量が格段と増えました。もはやWwise Unrealインテグレーションを簡単な橋渡しや単なる事例と現実的に呼べなくなりました。
今思えば、この時にWwiseユーザの考え方が根本的にシフトしたのです。シンプルなソリューションを提示し、開発者が独自パイプラインに固有の問題を自分たちで解消するという流れが変わり、WwiseをUnrealにインテグレートしはじめるとすぐにサポートに問い合わせがくるようになりました。この間私たちは優れた多くの開発者と共に、複雑性ゆえのワークフローの問題を解決しました。社内的には既存の枠組みの中で解決しようとする難しさが見えてきました。
すでに確立された4本の柱に依存し続けるのではなく、第5の柱として「Wwise Unrealインテグレーションのユーザ拡張」を追加する必要がありました。ゲームコード自体の中ではなく、やる気のあるチームが内部のコードを1行たりとも変えずに下位レベルでWwise Unrealインテグレーションの動作方法を変更し、拡張できる方法です。これを可能にするためにはコードのレジビリティにも注意し、Unrealコーディング規約はもとより、明確で簡潔なビルディングブロックを作成しながら物事を論理的なパーツに分割することを意識する必要がありました。最後にこれまでと異なる観点から自分たちのコードを見て、各要素を文書化する時にどう説明するのかを考えました。コードの意図が自明であるだけでなく、コードの説明もシンプルであるべきです。
何千もの外部プロジェクトで使われている10数年分のコードを変更することは決して簡単ではありませんが、この時点で必要でした。そこでWwise 2022.1から再生化のプロセスをスタートさせましたが、ユーザに見えるコード変更は最初はごくわずかです。アセット定義はほぼすべて内部的な変更です。現在Audio Deviceと呼ばれている箇所は開発者がここ数年でアクセスできるようになった操作の半分ほどのリストのようなものですが、いくつかの機能が削除されました。これを手はじめに、変更や将来の拡張性へのアクセスを提供するユーザ変更可能なモジュールとなる、低レベルコードを書きはじめました。
控えめな第一歩ですが、Wwise Unrealインテグレーションのさまざまなエリアにかけて提供される機能の概要をここで説明します：
開発者は複数の低レベルモジュールをアクセスできるようになり それぞれが拡張可能です（最も低レベルから順に）：
- Wwise Sound Engine: ほぼすべてのSoundEngine API操作への低レベルアクセス。これまでAkAudio外のコードをアクセスすることは不可能でしたが、APIを同じダイナミックライブラリでアクセスする必要があったためです。このモジュールで直接かつ安全にそれをアクセスすることが可能となりました。
- File Handler: Unreal EngineとWwise Sound Engineをつなぐランタイムファイル。両者を満足させようとします。WwiseストリーミングのI/O Hook、SoundBankローディングマネージャ、そしてMediaローディングマネージャが含まれます。さらにExternal Sourcesを使用するゲームが実装すべきExternal Sourcesマネージャスタブも含まれます。
- Resource Loader: どのWwiseアセットタイプにも、そのアセットをロードするために何が必要なのかを含むLoad Data構造ができました。高レベルコンポーネントからのリクエストを受け、Resource Loaderモジュールが必要なものをFile Handlingモジュールに向けて列挙し、 アンロード時に戻します。同様に任意のSwitch Containerの最適化も行います。
- Project Database: Unreal Editorが使用するためのWwiseプロジェクト情報のロードを処理します。イベント、すべてのAUXバスのリスト、スイッチ、ステートなど、Wwiseプロジェクトのすべての利用可能なデータポイントのリストを含みます。
- Resource Cooker: 上記Load Data構造を作成するためのアセット情報を取得し、パッケージング中にWwise Generated SoundBanksバイナリファイルをステージングし、Resource LoaderやFile Handlerで利用できるようにします。
これらのモジュールはWwiseプラグイン内にある既存のモジュール AkAudio や AudiokineticTools の隣に追加されます。
Wwiseをゲームエンジンとインテグレートする時に開発者が総括的な判断を下すことができるよう、インテグレーションコードはこれまでに複数のアプローチを経てきました。無限にユーザが変更可能な初期のコード例にはじまり、1つのワークフローに限定されたシステムとなり、さらにユーザコミュニティから要求された多くのユーザリクエストのワークフローが可能となりました。
ワークフローの簡素化：SSOTとパッケージング
私たちは開発者やサウンドデザイナーが効率よく開発できるように、よく定義されたインテグレーションを達成するためのはっきりとした道のりをWwise 2022.1のUnrealインテグレーションで提供したいと考えました。安定性があり拡張可能で、理解しやすいコードとすることで、選択肢を無駄に複雑にすることなく、開発者が自分独自のパイプラインとワークフローに適していると判断した境界を押し広げることができるようにしたいと考えています。
Wwise Unrealインテグレーションの背景
Wwise 2019.2と2021.1ではWwiseアセットが異なる場所にありました。まずWwiseプロジェクト自体にありますが、それがUnreal Assetsとして複製されて保護されたContentフォルダに入れられます。WwiseとUnrealの間の変更点の同期はWwise Authoring API（WAAPI）経由でも行い、Wwise Work Unitからのパースもあり、ほかの方法ではアクセスできない情報があるためWwiseプロジェクトファイルへのアクセスの依存性が発生しました。
ソースが分岐され増幅してしまい、特にUnreal Editorが閉じている時に変更がある場合などは、問題が発生しかねません。読み込み時にこれらのアセットを優先順位付けして同期するため、制作や編集の段階で許容できないほどのスローダウンや不明瞭さが発生します。Wwiseで1つのルートフォルダの名前を変更するという単純な行為だけでも複数のエンジンで何千という名前変更の処理が発生することがあり、それぞれ数秒ほどのコストがかかります。
実際には小さなプロジェクトでこそ便利に思われる方式ですが、大規模なプロジェクトではシンプルさを謳うわりにコストが高すぎます。
これらのアセットを最終プロダクトとしてクックする際、Wwise Unrealインテグレーションの最初のイテレーションでは、ユーザがすべてのSoundBankファイルやMediaファイルの入ったクック用のフォルダを追加する必要がありました。残念ながらこのフォルダに補足的なメタデータファイルも含まれるためゲームサイズが大きくなってしまい、悪意あるユーザにハックされやすくなる恐れもありました。
Wwise 2019.2以降はレガシーワークフローを使用する場合を除き、これらのWwiseアセットがバイナリバルクデータとして必須のUnrealアセットにバンドルされます。機能的な方式ですが、UnrealアセットとMediaやBankアセットの関係を1対1とする原則があります。さらにUnrealの容赦なきアセットライフタイムサイクル次第という面があります。
Single Source of Truth（SSOT）
Wwiseアセットやプロジェクトのデータベースは、Generated SoundBanksフォルダ1箇所とします。
これが私たちの新しいSingle Source Of Truth（SSOT）です。生成されたバイナリファイルがあり、ほかにもWwiseプロジェクトやその出力を理解するために必要なすべての情報を含む生成されたJSONファイルがあります。Unrealアセットが任意となり、中に含まれるのは参照するWwiseアセットの分かる識別データだけです。
Wwise PickerはWwise ProjectではなくGenerated SoundBanksフォルダにリンクするようになりました。
レガシーワークフローにおいてUnreal Editorで再生されるのはGenerated SoundBanksフォルダの中にあるもの、またはEvent-Based Packagingワークフローの一部としてUObjectsの中にあるものでした。このような状況でWwise Pickerを通して表示される内容もまた完全な真実ではなく、前にWwiseプロジェクトで保存された内容となっていました。Source Controlから取得する情報とGenerated SoundBanksフォルダの内容が同じである可能性は高いものの、この想定を確認する仕組みがありませんでした。今回Wwiseプロジェクトがインテグレーションに完全に無視され、Wwise PickerにGenerated SoundBanksフォルダのみを使うようになりました。
WAAPI PickerはWwiseプロジェクトに対する単なるビューポートとなりました。
WwiseがGenerated SoundBanksフォルダに対して生成するアセットやメディアこそ、このプロジェクトの“Truth”となりました。これらのアセットが再生されUnrealインテグレーションの一部として表示されます。ただし便宜上、引き続きUnreal EditorでWAAPI Pickerを使用してWwiseプロジェクトとAuthoringの間の操作を行うことができます。これが“Truth”となることはありませんが、便利です。Wwise Authoringの変更内容をエディタにプロモートするためには、生成する必要があります。
サウンドデザイナーはWwiseを知っていますが、開発者全員が知る必要はありません。
常にWwise Authoringインストールの完全版とWwiseプロジェクト全体をアクセスできた方が便利なのは確かですが、プロジェクトにかかわる開発者全員がWwiseについて知り、インストールする必要はありません。Wwise 2022.1ではワークフローが最適化され、Wwise Authoringやゲームの完全なWwiseプロジェクト（特定プラットフォームのパッケージングを含む）がなくてもWwiseを 含む Unrealプロジェクトの開発に携わることができるようになりました。現在ではWwise Unrealインテグレーション（対応するSound Engine SDKを含む）と、任意の場所に移動できるGenerated SoundBanksフォルダだけが必要となっています。同時にGenerated SoundBanksフォルダもUnrealプロジェクトのContentフォルダの中ではなく、好きな場所に置くことができるようになりました。
Wwiseバイナリアセットは不要なファイルの除去が行われ、必要なファイルだけがパッケージ化されたプロジェクトにコピーされます。
Wwise 2022.1では、アセットをパッケージされていないファイルとしてランタイムで使用するためにコピーする、過去のシステムに戻りつつあります。Unrealアセットのライフタイムに制限されることがなく、ベストなシステムです。ただしEvent-Based Packagingシステムからの学びを活かし、使用したファイルはそのUnreal Assetsの利用に基づいてステージングします。このプラグインはAk Componentsを利用して最終ステージングで何が使われているのかを判断し、通常のUnrealアセットを使うプロダクトをシームレスにします。最後に、これらの処理をオーバーライドできるようになったため、開発者はインテグレーションコード全体を書き直すことなく、自身の制御の下で、ファイルの読み込み方を変える特別な操作や、ファイルに対して複数の処理を行う機能など、必要に応じてこれらのファイルの扱いを変えることができるようになりました。
Wwise Authoringは私たちのデザインツール
ここ数年間、UnrealインテグレーションではWwise Authoring内のSoundBank Generationを基本的に迂回するようなワークフローを掲げてきました。プロジェクトによっては今もこの方式の方がふさわしいと考えられる理由はいくつもあります。Authoringはもともとモノリシックなサウンドバンクを含むフォルダを介してファイルを提供するように開発されましたが、ストレージへのアクセスの加速化や、ディスクドライブからソリッドステートへの移行もあり、メディアへのランダムアクセスの対応能力が一般的に向上しました。複雑なWwiseプロジェクトでは今もサウンドバンク経由でプロジェクト情報を提供する方法が最も効率的ですが、業界ではパイプラインの一部として独立したオンデマンドアセットを要求する動きが高まっています。このような状況に対する私たちの最初の試みがEvent-Based Packagingであり、AuthoringとUnrealユーザの間の距離がさらに広がりました。
しかしサウンドデザイナー専用の別のツールを提供するという考え方や理想により、ゲームオーディオとゲーム本体の開発を完全に並行してすすめることができ、例えば3Dアーティストが3Dアセットを作成して維持するために別のツールを使うのと似て、効率性だけでなく簡素化のために依然として有効です。複数のバージョンを経るうちにこの考え方のメリットが損なわれてしまい、考え直しとプライオリティの整理が必要でした。
Wwise 2022.1はAuto Defined SoundBanksをWwise Authoring内で直接提供します。これはすべてまたは一部のWwiseイベントを、独立した専用のサウンドバンクで定義するオプションです。結果的にEvent-Based PackagingのパワーをどのようなインテグレーションやUnrealにおいても利用できるようになり、Event-based Soundbanksやそのメディアの詳細な管理が、どのゲームエンジンにおいても簡素化されます。
この根本的な変更により私たちのUnrealワークフローは後退し、以前のワークフローが実質的に排除され、サウンドデザイナーがWwise Authoringでサウンドバンクを管理する、という考え方に逆戻りしました。
今回、私たちはこれまで忘れられていた次の2つの開発者タイプをターゲットとします：
- Wwiseを全く使わない開発者（Game Play、AI、GFX、3D）
- Wwiseだけを使い、Unreal Editorを全く必要としないサウンドデザイナー
アセットサイズやメモリ使用の管理責任はWwiseとサウンドデザイナーに戻されましたが、この点が今までのWwise Unrealインテグレーションに欠けていたのです。サウンドバンク生成情報パネルをアクセスできるようになり、特に比較的小さいプラットフォームにおいて、ゲームのリソース要件に対応しやすくなりました。
最後に残るワークフローはテクニカルサウンドデザイナーたちに焦点をあてたもので、彼らはEvent-Based Packagingの成功点を喜んで受け入れてくれ、開発段階でUnreal EditorとWwise Authoringを交互に使うような人たちです。WwiseとUnrealを行ったり来たりしている人に、新しいワークフローは「スピード」と「一貫性」をもたらします。常にWwiseとUnrealの同期をとる必要がなくなり、同期が必要なタイミングを正確に把握できます。何時間もかかってしまうような操作（前述のルートフォルダの名前変更など）を引き起こす心配をせずに作業できます。
Unreal用のオーディオ開発と、ほかのゲームやミドルウェア用のオーディオ開発の間で、ワークフローの違いがなくなります。
サウンドデザイナーはWwise Authoringで直接、ゲームのための最高オーディオエクスペリエンスをつくることに集中できます。Unreal Engineでゲームを開発するからと言って、アセットの開発・管理の隠れた機能や特別な方法はありません。
Wwise ProjectフォルダはUnreal Editorで作業するために必要ありません。
サウンドバンクを別のフォルダに直接生成できるため、これが最終ゲームでオーディオを入れバンドルするための唯一の要件となります。Wwiseからサウンドバンクを適切に生成できる限り、ゲームをパッケージングするために必要なものはほかにありません。
Unrealプロジェクトで夜間のCommandletメンテナンスが不要となります。
サウンドデザイナーが変更を加えた後のUnrealのAsset変更が膨大となることがあるため、チームによっては必要な作業でした。これからのサウンドバンク生成はサウンドデザイナーが自分のマシンで直接行うか、サーバでGenerated SoundBanksフォルダだけを変えるように自動化できます。同様に、生成されたWwiseプロジェクトのCacheフォルダをソースコントロールにコミットしてチーム全体で共有する理由は減ります。サウンドデザイナーがWwiseプロジェクトを独占的に制御できるようになるためです。
テスト可能性
WwiseもUnreal Engineも広範囲のカスタマイズが許容されます。最高品質のプロダクトを確実に提供するために、Audiokineticには経験豊富で能力の高い専任の品質保証チームがありますが、開発者がWwiseを使って試みる使用方法をすべて確実にテストできるわけではありません。多くのソフトウェアは1,000個ほどのオーディオアセットと共に届くものですが、中には100万個以上のものもあります。さらにプラットフォーム制限のためにすべてを再生できないものや、10種（以上）の言語が含まれるもの、ストリーミングメディアの限界に迫るもの、1つのイベントにオーディオの選択肢が1万個あるもの、マップを動的にストリーミングするもの、ほかの誰も使ったことがないようなつかみどころのないUnreal機能を採用しているものなど、いろいろあります。また私たちのコードやUnrealのコードを拡張、修正するなど、非常に特殊な自分たちのニーズに合わせていく優れたチームの存在を忘れてはなりません。特定のUnrealバージョンだけに対応すること自体が普通ではなく、大規模なゲームではUnreal Engineの複数のバージョンを手作業のカスタムコードで統合し、独自のカスタムバージョンをつくることがよくあります。
今私たちがフォーカスするのは最も一般的な「中間地点」ですが、あるチームが独自プロダクション用にWwise Unrealインテグレーションをダウンロードし、私たちが思いもしない、当然ながらテストもされていないようなエッジケースに遭遇する可能性があることも承知しています。
このWwise 2022.1 Unrealインテグレーションの初期バージョンは、一歩後退すると共に大きく前進しています。初期の最適化が適切なコードづくりの最大の敵であることは周知の事実ですが、大半のゲームで喜ばしいと感じてもらえる理性的な範囲の最適化レベルは維持されています。これまで複雑なコードパスゆえに負荷となっていた点はすべてシンプルにしました。ログ記録を追加し、コード品質を改善しました。
ツールとフレームワーク
Wwise Unrealインテグレーション全体をさらにテストしやすくするための基本的なツールやフレームワークの開発がはじまりました。すぐにすべてを提供することはできませんが、完全にテスト可能なWwise Unrealインテグレーションへのコミットメントは今後数年にわたり続きます。その第一歩となる取組みが Gymsの開発 です。
これは以下のように複数のゴールがある外部プロジェクトです：
- Wwiseプロジェクト1つ、Unrealプロジェクト1つ、Unityプロジェクト1つを含むプロダクトです。
- 1つのマップで1つのコンセプトを簡単に効率的に説明するような、複数の小さなマップがあります。ユーザが使える事例があります。
- 小さいマップの1つ1つに、インテグレーションをポジティブとネガティブの両方でユニットテストできるコードへのリンクとエッジケースがあります。すべてをミドルウェアが推奨するユニットテスト方式で行えます。
- 外部開発者がアクセスできます。カスタマイズしたフローを開発者がテストし、さらにイテレーションできるように復元ケースをマップとして共有するためです。
サードパーティのレポジトリでGymsを公開し、Wwise 2022.1から維持する予定です。
ほかにも低レベルモジュールの拡張性デザイン自体を含むさまざまな改善策が計画されています。次回のメジャーバージョンに合わせてユニットテストモジュールの提供を開始し、開発者が分かりやすい仕組みを利用して自分たちのエンジン変更をテストできるようにしたいと考えています。
まとめ
今のWwiseは10年前の姿とは異なります。その間Unreal Engineも急速に発展しました。「維持すること」は単に互換性を保ちながらいくつかの機能を少しずつ追加することを意味するものではありません。使う開発者が喜ぶようなプロダクトであることも大事です。Wwiseインテグレーションを使うチームたちは長年ベストな処理能力、安定性、そして機能性を誇る最終プロダクトを作成するパワーを私たちに求めてきました。
この最初の記事では私たちの考え方がどのように変化し、どのような大がかりな要件を伴ったのかについて紹介しました。何を優先すべきで、そのためには何が必要なのかを自問自答することで、Audiokinetic社内のインテグレーションのとらえ方全体を変えるプロセスがはじまりました。WwiseをUnrealに適用させること、そして強固な「背骨」をゼロから作り直すこと、この2つを意味します。
今、私たちはWwiseインテグレーション2022.1で、開発者もサウンドデザイナーも次のサクセスストーリーをつくりやすい、新しく現代的なシステムの基礎を敷いています。それは多くのユーザが今後出会うであろう課題を解消するための、充分に現代的でありながらこれまでのプロダクトとの互換性の大部分が維持される安定した基礎となります。
コメント