Wwiseエコシステムの中でも、実はWwiseの拡張性は認知度が最も低い特徴の1つです。各社は自分のプロジェクト用に独自プラグインを作成し、ベンダーは自分のプラグインをWwiseに移行し、ときには私たちもヘルプします。もうすぐWwiseの新バージョンがリリースされますが、私たちの誇りであるこのシステムが、初めて大々的に再編成されます！

このブログ連載で、WwiseのAuthoringプラグインのデザイン面での選択肢を紹介しながら、新しいAPIのお披露目をしたいと思います。

• パート I: 経緯と目標
• パート II: プラグインの内部
• パート III: プラグインをつくる

パート I: 経緯と目標

プラグインは、Wwiseビジョンの中心にあります。エフェクトやソースを使い、あなたのプロジェクトに特別な「何か」を追加する能力。もしWwise Launcherから任意でインストールできる、何十とあるプラグインに満足できなくても、表面に現れないものが多数あります。バンドル化されたプラグインは20以上あり、コミュニティプラグインの数も増え続けています。

どのプラグインも2つに分かれていて、あなたのプロダクトの実行ファイルにバンドル化されるSound Engine内の部分と、あなたが希望する通りに設定するための、Authoring内の部分があります。

レガシー

この15年間でプラグイン制作のシステムが洗練され、AuthoringとSound Engineの両方と、密接に統合されてきました。あまりにも密に統合されたため、プラグインの基盤や関数が、内部で、ほかのものをビルドするために使われてきました！

明らかにこれは両刃の剣です。システムは緊密に統合され、最適化されていないパスはない、ということを意味します。同時に、内部構造のリファクタリングや変更を行おうとしても、できません。内部構造を変えることはできませんが、プラグインのインターフェースをくっつけてバージョン間の互換性を保とうとしました。

さて、Sound Engineについては、プロダクトを効率的に素早く実行する必要があるので、今はこれで理にかなっています。ところがWwise Authoringは、すべてがWindows APIベースとなっていることが、負の要素となりました。

時代は変わる

私たちの本業は全プラットフォームの現行世代と次世代をサポートすることですが、Authoring側は脱線してしまいました。Sound Engine側では、私たちのチームが不断の努力で新SDKや新プラットフォームの対応に務め、製品を出荷するお客様向けの修正や改善も、私たちは同時に最善を尽くしてきました。あなたのプロダクトのサポートマトリクスが巨大だと思ったら、私たちのビルドマシンを、試しに見てください！ところが、Authoring側は、長年、WindowsバージョンとポートされたMacバージョンでお客様から良しとしていただきました。

私たちの「夢」と「優先順位」からして、徐々にクロスプラットフォーム性の改善が必要だということがはっきりしてきました。15年前にXboxとWindows PCが最初の対応プラットフォームとなって以来、シンプルさのために、Windowsと密に連携するという決断は簡単でした。その後、年を追うごとにインターネットが広まり、ゲームはストリーミングされ、開発者はLinuxをバックエンドサーバとして使い始め、同時にスマホの世界をiOSとAndroidが乗っ取り、Macもかつての栄光を取り戻してクリエイティブプラットフォームとして好まれるようになりました。1つのプラットフォームコードベースだけでは、マイナス面が目立ち始めたのです。

プログラミング言語とて同じことです。TIOBE IndexによるとC++の使用はピーク時の16%以上から6%にまで落ち、新参者のRなどが進化を続け、Pythonがあえて選ばれるようになりました。15年前のコードのC++をそのままコンパイルしてもC++17になりません。プログラミング方式さえも同じです。ユニットテスティングメソッドの人気は上昇し、かつてはMicrosoft ProjectのWaterfallが一般的だったのに、今ではScrum開発方式が多くの会社文化の一部となりました。Appleは独自CPUをもち、Microsoft Visual StudioはAppleデバイス向けのコードを生成し、Mac上で実行することもできます。私たちも、ようやくray tracingを取り入れ、ほとんどのユーザーのCPUが4コア以上です。15年もあれば、色々と変わります！

一歩ずつ前進…

4年前に、問題の表面的なレイヤだけを見直すのではなく、根本的な原因を摘まみ出す作業を開始しました。ただ、スイッチ1つで、C++コード（2017）が220万行も入った12,000個のファイルを変更することはできません。時間とやる気が必要です。プラグインコードだけでも、今となっては何百という関数が含まれ、その多くは、初めてのバージョンが出荷されてから、手を加えられたことがありませんでした。すべての部品を、慎重に落とし込みながら、常にプロダクションにおける安定性を維持し、人にはわからないようにフィックスする必要がありました。

簡単な例でいうと、Authoringコードはほとんどがワイド文字、つまり1文字あたり2バイトです。私たちのプラグインも、それを反映してきました。また、Windowsでワイドは2バイトなのに対し、Macでワイドは4バイトなので、結果やコードがプラットフォームによって異なりました。4年間の間に、UTF-8がクロスプラットフォームの開発向けとして、徐々に質が高く標準的な選択肢となったので、基盤の多くをUTF-8に移行するプロセスを始め、その結果が、2019.1と、2019.2のリリースに出始めてきました。まだまだ先は長いです。

別の例も紹介します。偉大なるWwiseCLI実行ファイルのおかげで、今もWwiseをコマンドラインで実行できますが、作成当初はあとからの思い付きのようなものでした。その実行ファイルが、バックグランドで全グラフィカルインターフェースを実行していました！そのグラフィカルインターフェースは、Windowsと緊密に統合されていたので、2年ほどかけてリファクタリングをして、インターフェースをクロスプラットフォームのロジック部分と、Windows GUI部分とに分割したあとに、WwiseCLIを2019.1でやっとオーバーホールし、ロジック部分だけを実行し、フロントエンドのコマンドライン だけ ではなくなりました。でも、そこで終わりにしたわけではなく、そのまま続けてWwiseConsoleのコードの改善や最新化を進め、2019.2リリースの一部としました。

プラグインの再考

2019.2で、新プラグイン関連の動きが本格化し始めました。ユーザーの知らないところで、最初の次世代プラグインが、プロダクション最中にリリースされ始めました。もちろん簡単なプラグインでしたが、それでも、です！安定性についてフィードバックを集め始めると、最善のことが起きたのです。フィードバックはわずかしかなかったのです！今となればレガシーにあたるプラグインと、新しいプラグインとの間に、明らかな違いが感じられなかった、という意味です！（パフォーマンス中であっても。）一部の関数は遅くなり、すべてブリッジされている状態ですが、プラグインに新機能を実装するのがずっと簡単になったということでもあり、Wwise Authoringのパフォーマンスも改善しやすくなりました。

つまり、2019.2以降はレガシープラグインと新プラグインを並行してサポートしてきたわけですが、今後も、意味のある限り続ける予定です。

2021.1 新プラグインAPIの目標

魔法の水晶玉を見ながら

初代のプラグインバージョンは、15年以上前にAuthoringと共に作成されました。今回のバージョンで、Wwise Authoringが今後15年間、成長を続けられるはずです！そもそもプラグインインターフェースが常に変わっていたら、意味がないので、これが一番大事な目標です。

この点が今回、ほかのすべての目標に反映されています。

どのプラットフォームのプラグインも可能に

Wwiseが対応するどのプラットフォームでも、プラグインコードは同じになるべきです。今後のAuthoringエクスペリエンスがどのような展開を見せるのか、誰にも分かりません。私たちは、クロスプラットフォームのプロジェクトを開始したときに、ネイティブのMacとWindowsの実行ファイルを希望し、できるだけ早くグラフィカルインターフェースが欲しいと思いました。当初はグラフィカルインターフェースなしのバージョンがあるのもいいのでは、と考えました。最初の結果が出ると、実はアーリーアダプターたちがサウンドバンクをLinuxでも生成したがっていることが判明しました。これは、まだ手始めの内容です: コマンドラインを通した効率的な生成、WAAPIサーバ、UnrealやUnityとのヘッドレスで緊密な統合。ハンドヘルドデバイスの機能性の向上に伴い、最終的にどこにたどり着くのかは、誰にも分かりません。

C++は万人のためではない

ご存知の通り、C++はプラグイン開発に使える多数の言語の1つにすぎません。最近は、複数のプログラミング言語を使ってプラグインを作成したいと思う人が増えてきました。21.1では、Sound Engine用にPythonで実行するコード例まで提供されます！プラグインを制約したくないのです。「プラグインは最適化された言語で」という考え方はC++ではもちろん、ほかの言語でも確かに言えることです。

このため、新AuthoringプラグインはC基盤があり、ABIとAPIで安定化です。新しいバージョンでも、インターフェース全体が、どの言語で作成したプラグインにも安定性をもたらします。提供される モダンなメタプログラミングブリッジのおかげで、C++ プラグインを簡単に効率的に作成できます。

最良プラグインは、無いプラグイン

Sound Engineプラグインは、機能性を拡張するために必ず必要となります。それでもプラグイン全体をAuthoring側なくして作成できるとしたら、それが最良です。可能な方式が何百ともあるので、最も単純なユースケースを実現するパイプラインを作成することの優先順位は、高いです。

後方互換性

プラグインをこれほど多く変更すると、プラグインベンダー側の作業量が増えることが当然予想されます。私たちは、この過程をできるだけシームレスにすることが目標です。だから、レガシーのプラグインも存続しています。最適ではありませんし、プラグインはクロスプラットフォーム対応になりませんが、最新の21.1 SDKでプラグインを再コンパイルするだけで、デフォルトでWindowsで使えます。

今後のバージョンでも同じです。希望するSDKバージョンを設定し、最新バージョンでコンパイルして戻せば、可能な限りインターフェースの互換性が保たれます。

いずれは後方互換性が負担になってくるので、この仮のブリッジは後々削除されるものですが、問題が発生しない限り維持されます。

まず最初に消去されるのは、クロスプラットフォーム対応を外してしまうレガシー用ブリッジです。ただし21.1ではフィックスが必要なものはありません。

バージョン付きで、今後の拡張あり

コードは引き続き永続とされ、リリースをまたいでトランジションされるので、インターフェースへの追加、変更、削除などの変更が予想されます。簡単な例を1つあげると、21.1では、クロスプラットフォームのGUIはまだ提供されていませんが、これはまず、Authoring用の切り替えをするためです。またプラグインタイプは、例えばコンバージョンや分析のプラグインは、技術的にはサードパーティベンダーが行うことができますが、現在、それらを実装するのは不可能です。

なんでもテストする

これだけ変更が多いのは、FUD（恐れのFear、不安のUncertainty、不信のDoubtの頭文字）を意味します。長年に渡る作業は無料ではなく、私たちはGood Thing™を行いたいと考えています。Wwise Authoring部分は、プラグインのほかの部分を試してみるのにちょうど良いテストベッドです。もしかしたら、これがSound Engine改良のベースとなるかもしれません。なんだってあり得ます。

Wwiseエコシステムの中でも、実はWwiseの拡張性は認知度が最も低い機能の1つです。各社は自分のプロジェクト用に独自プラグインを作成し、ベンダーは自分のプラグインをWwiseに移行しようと考え、ときには私たちもヘルプします。もうすぐWwiseの新バージョンがリリースされますが、私たちの誇りであるこのシステムが、初めて大々的に再編成されます！