使用Unity5開發手游，使用FMOD或wwise音頻插件而不是自帶的聲音系統有哪些好處？

01-06

很多知名的手游，如王者榮耀、劍俠手游、崩潰3rd等等都使用wwise。使用它有什麼好處嗎？我所理解的可能性：
1、性能更好（這個可能不是非常成立，因為Unity本身也是FMOD實現的音頻系統）
2、更好的音頻效果（這個有點不太理解，只要音效師調整好了最終輸出一個wav文件就好了。是不是藉助插件可以用現有的聲音文件進行混音處理從而呈現更加豐富的音質效果？）
3、為了跟音效師或外包公司配合，音效師調好一個bank文件直接丟過來在遊戲中就是正確的效果而不需要考慮引擎的兼容性。

碰巧對Unity里的聲音腳本，FMOD和Wwise都比較了解，強答一下。音樂和音效還得分開說，因為這兩個很多時候需求和設計很不一樣。

首先，簡單的2D遊戲大部分時候是用不到這兩個中間件的，除非是音樂遊戲。而3D遊戲尤其是第一人稱視角的遊戲中就比較有必要。中間件最強大的地方在於自帶的那些效果器，用於3D音效的空間處理，這點在沉浸式體驗的遊戲中非常重要。FMOD和Wwise中帶有各種DSP的實時運算處理插件，用於聲音在真實場景中的渲染，而Unity引擎中除了加一個Low/High Pass Filter和非常基本的Reverb之外幾乎沒有任何可以控制的地方。FMOD擁有天氣環境音效的生成器，Wwise還帶有一些物理建模的插件來模擬揮舞聲、風聲和擊打聲等，可以為遊戲節省一些資源空間。如果要做AR/VR的遊戲，就更加需要中間件進行空間化處理了。據說Wwise現在在開發智能分配通道的功能，也就是說不管玩家的播放設備是什麼樣的，單聲道/立體聲/5.1環繞聲/VR也好，都能將當前聲音在聲場中的位置自動分配相應的音量到每個通道上。

在音效上，最讓程序員頭疼的就是資源管理。音效師做出來的資源往往只有自己才能數的清，程序員在不進行大量溝通的情況下很難理解每個子文件夾都是做什麼的，這點對於大公司的開發團隊尤甚。舉個例子，當我需要做某個怪物的腳步聲的時候，哪怕是最簡單的隨機選取不重複機制，如果在Unity里直接寫，都需要先把某個精確路徑下的文件載入到一個AudioClip[]里，然後隨機選取再檢測確認與上一個不重複。還需要考慮一個AudioSource同時只能播放一個AudioClip，如果聲音的尾巴比較長的話，會打斷，所以可能還得放多個AudioSource，或者根據之前的腳步聲有沒有播放完來決定是否Instantiate另一個AudioSource然後等到播放完再Destroy。這些在程序上實現並不難，但是很煩人，也可能會產生bug。不像動作特效上的bug一眼就能看出來，程序不懂音頻技術還不一定聽得出音頻上的bug，最後給項目開發帶來很多額外的工作量，影響開發效率。而且，我就沒見過幾個程序員戴著耳機工作的。

還是腳步聲的例子，如果我要做出不同的怪物在不同的地面上發出不同的腳步聲，以上工作量就大得多。但是如果使用中間件，尤其是Wwise的話，程序員只要做一個簡單的Raycast然後把結果對應相應名字的Event就行了，幾十行的代碼簡化成了一行。所有的這些隨機/避免重複/不同怪物/不同地面/voice數量等等都不需要程序員來考慮，交給音頻設計師在中間件里完成就行了。中間件對於音效帶來的另一個好處是能夠對不同聲音事件進行優先順序判斷，砍掉不重要的聲音或者音量太小的聲音，提高遊戲性能優化。這個在Unity里雖然也可以做到一些基本的，但可控性比較弱。

另外就是聲音的動態變化。Unity居然不支持最簡單的聲音淡入淡出，需要專門去寫一個Coroutine。比如賽車遊戲中引擎的聲音，往往有很多個樣本文件，在不同轉速下進行cross fade。在Unity裡面要實現這個無縫漸變是比較困難的，但是在中間件里，只需要程序員把引擎轉速的變數與FMOD中的parameter或者Wwise中的RTPC在Update裡面進行賦值對接就行了。

還有一點就是對於資源包的管理。不管是配樂還是音效，導出的原始文件都是wav格式，佔用大量體積。而FMOD和Wwise里都可以針對不同的平台進行不同格式以及大小的壓縮。Wwise甚至能夠對每一個音頻文件自動檢測可承受的壓縮範圍，以保證資源包的最小化，這點在手游上尤為重要。在遊戲運行過程中，中間件也可以選擇針對不同的音頻進行不同的預處理，如常觸發並需要快速反應的音效就載入內存中，音樂和環境聲就從磁碟上stream，這一點優化是Unity做不到的。不管是FMOD還是Wwise，都能夠跟Unity直接連接，通過Profiler來實時查看音頻部分在遊戲中CPU與內存的消耗，以便進行更好的優化。音頻設計師也能夠更方便的測試自己做出來的聲音在遊戲里不同情況下的播放究竟是什麼效果。

說完了音效來說音樂。如果只是播放一個BGM的loop，是用不到中間件的，但是現在講究點質量的遊戲都會進行動態音樂或者互動音樂的設計，而這一點在Unity里是沒有任何技術支持的。我曾經自己用C#寫過動態音樂判定的播放規則，包括分層播放以及段落轉接。雖然不是非常複雜，但畢竟音樂和程序都是我自己寫的，不會有溝通理解上的困難。在大多數現實情況中，程序員不懂音樂，音樂人也不懂程序，如果不用中間件，很難完美地完成音樂人想要的播放效果。

在手游上，尤其是休閒遊戲中，許多音效是音樂化的，這就在觸發時間上有了要求，我們叫做stinger。比如玩家在吃掉一個物品獲得技能時，在音樂中插播一小段旋律或者鼓點。在Unity中無法做到讓這些stinger卡在節拍上，除非專門去算每首音樂的節拍換算成每一拍的毫秒單位，然後加一個計時器進行除余（程序員聽到這麼複雜的需求很可能就覺得算了懶得弄）。

更複雜的是音樂段落之間的對接。音樂文件往往要留著最後的尾巴，因此時長比實際音樂的時間長。如果不留有尾巴，就會聽到「噗」的一聲，音樂好像突然被切掉了。在音樂之間切換的時候，如果不用中間件，程序員必須知道實際音樂的精確時間長度，而無法通過簡單的AudioSource.isPlaying來判斷是否進入下一段音樂。在FMOD和Wwise中，這個問題都可以非常簡單地解決。Wwise還帶有Pre-entry功能，讓音樂開始前的前奏提前播放，達到更加智能的播放效果。

Wwise在音樂上的探索還遠不止簡單的播放分層/段落等方法。在演算法生成音樂上都有了技術上的嘗試。音樂人在編曲的時候先寫好MIDI音符，再通過MIDI音符觸發對應的採樣文件來生成音樂。遊戲的高互動性決定了這種預先寫好的音樂是不夠動態的。在Wwise中，能夠支持簡單的採樣器功能，將音符採樣導入，然後根據不同的遊戲狀態播放不同的音符。未來我們很可能會見到旋律永不重複的音樂遊戲，就是通過這樣的技術來進行音樂的動態生成，只要音樂人提供一個演算法並將控制點與遊戲中的參數對應。這對於絕大部分遊戲而言是用不上的，但是中間件為這樣的遊戲設計提供了可能。如果在遊戲中單獨寫一套AI作曲系統，開發的難度和工作量可以單獨做一個遊戲了。

最後，說白了，對於中小規模的手游，使用中間件更大的好處是讓本來就不多的程序員從音頻部分中解放，只需要負責遊戲本身的開發就可以了。本身小製作成本的遊戲使用中間件也花不了多少錢，但是為程序員節省了大量的時間來重新造輪子，也讓音樂人/音效師對自己製作的東西有更好的把控。對於大型遊戲而言，中間件能做到一些Unity本身無法做到的功能，同時在音頻的資源管理上省去了很多扯皮的麻煩。

作為一名遊戲音頻設計師，這個問題被問到過很多次。幾句話很難說清楚，正好趁這個機會寫下來。希望越來越少的設計師會被問到這個問題。（FMOD、CRIWARE我都不夠熟悉，以下只從Wwise的角度說。）

Wwise裡面有很多很炫酷的功能，有些可以增強聲音的交互性、有些可以提高聲音的表現力、還有些可以提高設計師的工作效率。但是介紹這些功能的時候，往往被程序員一句「手游用不到這個」嗆得半天說不出話。

確實，在使用了Wwise的手游項目中，我們也僅僅使用了它很少一部分功能。但其中的一些功能，即使是對於手游來說也是絕對不可缺少的。

1、用Event封裝一切

對於Wwise來說，Event不只是一個AudioClip，而是一個或多個Action。這個Action可以是播放、暫停、停止一個SoundObject（一個SoundObject可能是多個wav文件），可以是控制某個聲音插件的參數來實現某種複雜的聲音效果，還可以是內部封裝的某些操作，比如切換混音狀態。這些Action有些只需要了解播放邏輯就可以完成，還有些必須了解數字音頻技術、效果器處理、混音理論才能夠完成。把這些操作全部交給程序員是不現實的。在Event封裝之後，程序員只需要在正確的時機調用PostEvent就好，完全不需要了解Event內部究竟發生了什麼。

2、音頻工作站級別的匯流排控制

匯流排（bus）這個概念對於非音頻專業出身的人來說可能有點陌生，這裡我不打算詳細的解釋這個概念。我們可以直接從應用的層面來說明為什麼匯流排對聲音很重要。

首先，最簡單的，我們希望在遊戲中，音樂、音效、語音可以分別設置音量大小及開關。藉助匯流排可以非常方便的實現這個功能。當然，即使沒有匯流排，程序實現這個需求也不是非常複雜。

那麼，進一步的。在遊戲進行的過程中，有時會播放CutScene。很多遊戲中，CutScene是通過在遊戲攝像機前又蓋了一層2D畫面實現的。那麼這個時候，有一個新的需求。如何讓玩家只聽到CutScene的聲音，而屏蔽掉被CutScene覆蓋的遊戲畫面中正在發出的聲音？到這一步，程序就很難實現了。因為程序很難判斷哪些聲音是在CutScene中發出的，哪些聲音是在遊戲場景中發出的。而Wwise依靠匯流排依舊可以非常方便的實現這個需求。

接下來。對於聲音設計師來說，聲音是有優先順序的，而聲音的動態範圍是有限的。玩家不可能聽到所有的聲音。Boss的技能總是要被聽到，而小怪技能的聲音優先順序可以稍微低一些，玩家的腳步聲只有在非常安靜時才聽得到。基於匯流排的混音功能可以滿足這個需求。優先順序高的聲音在觸發的時候可以動態的壓掉優先順序低的，使得在任何時候，玩家都能夠聽到設計師想讓玩家聽到的東西。很多缺乏混音處理的遊戲，聽起來雜亂無章沒有重點，往往就是這裡沒有做好。

針對匯流排最大發音數限制，是性能優化中非常有效的一步。王者榮耀還在這個功能的基礎上加上了RTPC控制，可以根據手機的性能、是否處於卡頓狀態等情況動態修改限制的數量。到這一步可以說，沒有中間件，是絕對無法完成這些需求的。

3、專業的音頻插件

雖然手機性能有限，用到的效果器種類比較少，但是基礎的混響及限制器還是會被用到。越來越多的專業效果器被集成在了Wwise中，一個好的效果器能夠讓遊戲聲音表現更上一層樓，而差的效果器足以毀掉設計師全部的心血。

除了效果器，我想重點說一下Wwise里的合成器。像饑荒這樣的遊戲，裡面60%的聲音可以通過合成的手段來完成。比如說背景的風聲，火燃燒的聲音，採集的Whoosh聲。（雖然饑荒本身可能並不是這麼做的。）聲音合成相比傳統的素材製作最大的優勢是聽感不會重複、零資源量、可以更多地和遊戲中的參數聯動。比如風聲可以通過程序定義風速的參數從而控制風聲的表現，這個風速還可以影響遊戲中樹的搖擺，使美術和聲音的體驗更統一。

相比數字音頻工作站中的音頻插件，Wwise內集成的插件可以獲得更強的交互性。所有插件的參數都可以根據遊戲中正在發生的事件平滑的更改。

想要了解更多可以參考Wwise官網。

Audiokinetic Plug-ins | Audiokinetic

4、交互音樂系統、打斷機制以及3D衰減

對於手游來說，很多地方的聲音設計都有所簡化。但是音樂系統和UI系統，這兩者相比端游是絲毫沒有簡化的。交互音樂系統、打斷機制、3D衰減這三個功能放在一起說，是因為僅從功能上看的話，這三者交給程序實現起來難度都不大。但是其中隱藏了巨大的溝通成本。

A音樂到B音樂切換時要播完當前小結再切換。B音樂到C音樂要立即切換，中間要做交叉淡化，Fade In 0.3s、Fade Out 0.5s。一個RPG手游，這樣的音樂切換點有幾千個。這些全讓程序來做？那收到的結果一定是一切換音樂，就聽到「咔」一聲。

遊戲中人物的對話，要後一句打斷前一句，或者根據不同的人物分別設置不同打斷。在戰鬥中，需要動態的觸發一些對話，這裡就要求前一句還沒說完的情況下，後一句不能打斷前一句，並且後一句不能和前一句同時播放。（崩壞3戰鬥中，戰鬥中觸發的對話頻繁被打斷，個人認為這裡的設計不夠好。）

3D衰減也一樣。要根據怪物體型、是否是boss，特效表現設置不同的3D衰減範圍。Unity自帶的音頻系統好像有這個功能，但是並不能像Wwise中，通過Audio編組加上Share Set功能方便的實現。

以上功能只是簡介紹了Wwise在手游開發中一定會被用到的功能，並沒有完整的表達Wwise的強大之處。Wwise里有些功能，例如基於採樣的粒子合成系統，可以做汽車引擎聲。這種聲音的需求只有通過中間件才能實現。

此外，理論上能實現和實際上能實現的差距很大。由於聲音在遊戲開發過程中優先順序很低，很多時候，一個很簡單的功能，直到遊戲上線也還沒有實現。程序員的工資挺貴的，把這個錢省下來買Wwise授權大家都開心。（請把軟文錢打我支付寶）

--------------------------------------------------------------------------------------------------------

以下是一些私貨

前面有答主提到，音頻中間件可以將程序員和設計師的工作分開，程序員只關注邏輯，設計師只關注表現。這個是非常對的。我們團隊更進了一步，自己有技術音頻，可以完全不依賴項目組的協助完成全部的音頻開發工作。項目組只需要提供項目的SVN地址，其餘的可以完全不考慮。

這樣做的好處是顯而易見的，聲音團隊可以百分之百的掌控遊戲聲音的所有問題，包括故障排除、性能優化部分。陰陽師、崩壞3這兩款遊戲都是用了中間件的，然而依舊有較多聲音方面的bug，並且好幾個版本都沒有解決。（比如陰陽師即使在設置里關了聲音開關，還是能聽到開場動畫的聲音。崩壞3很多技能在被打斷時，聲音還是會繼續播下去。開放世界的音樂總是錯誤的被切換。）這些bug大多發生在程序員和音頻設計師對接的中間地帶，這些問題對於程序員和設計師都存在盲區，加上聲音問題優先順序低，所以導致很多問題長期無法解決。另外，在傳統開發流程中，程序員開發的音頻編輯器使用起來非常不順手，某些機械重複的步驟會佔用設計師大量時間。我們自己開發配置工具後，這個問題也很順利的解決了。

這樣的開發模式已經持續一年了。幾個工作室的幾十個項目組普遍對這種模式表示滿意，設計師也能完全實現自己的想法。後面有機會的話，我會分享我們團隊的一些工作流程、開發經驗以及提升效率的工具。

用的不很多（我一般小型項目比較多，音效要求不複雜）

最近有個AR項目用的FMOD，因為本來就是音樂遊戲，總的來說Fmod或者wwise的好處還是在於功能比較強，比較接近音效師本來使用的軟體，而且分工比較方便。

有些類似隨機播放時間，多個音效clip循環等等的，氛圍音效無縫銜接等等，確實是unity本身無法實現的。

比方說類似《巫師》那種音效，有人聲，有氛圍音樂，這種就不是一整段樂曲可以解決，都是將音樂做成不同的片段，根據當時的狀態邏輯決定每一段如何銜接，這就有點隨機作曲的意思在，是非常高級複雜的玩法，必須得上fmod或者wwise了

但是，FMOD的文檔真是餵了狗了，裡面啥都沒有，我花了小一個月，請各種音效朋友們吃飯，才搞定一個最普通的load和播放。

之前研究過一陣Wwise，感覺最大的好處就是使用這些第三方工具，音效的製作可以脫離引擎本身，也就是音效師根本不需要去了解UE4或者Unity的邏輯，程序員只需要關心邏輯本身而不需要懂音效。

比如做一段飛機的音效，隨著距離衰減要在好幾個不同的音效之間進行crossfade，在引擎里做的話可能就得需要程序來介入，去調參數等等，工作分離出來之後只需要給音效師一個距離參數，各個音效的衰減曲線就可以很直觀的在這些軟體里看到了；還有一些需要random或sequence的音效邏輯製作也很方便；做一些特效混響也不難。

如果你的項目音效比較複雜，並且有外包或者專門的音效師，那麼建議使用這類的插件；如果只是小項目，不需要帶參數變化的音效，大部分音效直接扔進場景就能解決的話，還是用引擎自帶的就好，用插件反而增加了麻煩。

用fmod或wwise的最大意義在於將音效設計與程序開發分離。程序員只需要關心程序邏輯而不需要關心音效怎麼設計、好不好聽，音效師則關注於設計音效而不用理解程序。

舉個例子，做一個汽車引擎音效，音效師想了想，認為引擎音效與汽車速度有關，於是讓程序員提供速度給他，他去f或w里各種加工。程序員則負責運行時邏輯控制、資源管理、數據提供。

首先，在性能方面，Wwise/Adx2/Fmod等音頻中間件都針對優化性能做出了很多努力，提供給了聲音設計師多種手段，來追求效果/性能兩者平衡的最優解，同時又極大的解放了程序端在音頻功能支持上的工作量，這些都是Unity原生音頻組件所遠遠不具備的。

其次，在傳統的音樂製作領域，為聽眾呈現出最終的音樂前的最後製作環節是混音和母帶處理，這個過程可以為聽眾帶來混音師/母帶工程師對聽感的藝術理解，同時讓歌曲的整體聽感再上升一個層次，讓沒用的頻段讓位給有用的頻段，各個聲部的平衡達到理想狀態，並在聲學角度達到行業要求的標準。那麼在遊戲音頻領域，也同樣存在混音這個極其重要的環節，而遊戲的交互性則給混音帶來了很多不同於傳統音樂/影視行業製作方式的區別，而音頻中間件的出現，就像Protools/Nuendo/Logic等音頻製作軟體一樣為遊戲的實時動態混音帶來了可能，可視化的各種模塊讓聲音設計師更直觀的掌控遊戲音頻工程全局。想用Unity做到這一點，真心很累，聲音設計師和程序員都累，累完效果還有可能打折扣。混音絕不是針對某個音頻樣本的效果處理，那是音頻編輯/聲音設計，混音是全局性的聽感考量。

再次，引擎兼容性方面，Wwise/Adx2/Fmod等音頻中間件都有著多年的項目經驗積累和研發經驗，都分別對各個主流遊戲引擎提供支持，所以兼容性方面無需擔心。同時音頻中間件所帶來的新的音頻/程序協作方式可以極大的解放程序端的工作量，讓聲音設計師主導音頻工作的展開，讓專業的人負責專業的領域，優化工作環節，提高工作效率。程序端只需要專註於音頻相關功能的開發，而具體的資源解決方案則完全由聲音設計師來處理。

至於現在國產遊戲越來越多使用Wwise的現象，還有一個重要原因是Wwise官方對中國地區支持工作的重視和相關漢語資源的出現（感謝Wwise的北南老師和施颺老師），可以說在某些方面確實領先了同類的Adx2/Fmod等產品。

最後關於遊戲引擎原生音頻模塊方面，Unreal的Blueprint系統和Procedural Audio相關功能應該是領先了Unity，Epic Games的兩位音頻程序員Aaron McLeran和Dan Reynolds為Unreal帶來了很多新的音頻功能，今年的GDC也有一場專門的宣講會，講解並演示了Unreal Engine 4.16的很多新的features，相關視頻：https://www.youtube.com/watch?v=ErejaBCicds

以上回答沒有太多的介紹到具體的功能，因為具體內容涵蓋面太多不好碼字，想討論相關問題的歡迎私信我~

由於公司沒有音效師，程序和音效bank的製作都是我來，就以實際應用舉幾個我用到過的FMOD功能說幾個。

1.腳步聲、武器揮擊。可以在一個event中放置多個相似的音效。每次播放都會隨機播放一個，甚至可以對每次播放的音效在pitch上進行一定的升降調隨機，使音效不單調。而程序上要做的只是調用一下Play()就可以了。

2.bgm。任意設置循環區域就不多說了，更有趣的功能在於，可以踩著音樂節拍進行跳轉。比如遊戲進行到Boss第二階段，主歌需要跳轉到副歌，只要設置好節拍，曲速和允許跳轉的區域，在程序中將相關跳轉參數設置到閾值，音樂就會踩著節拍跳轉到副歌。

3.其他。Fmod支持大部分daw可以做到的大部分能力（當然軟音源和鋼琴窗是沒的），可以用一個參數控制Reverb的乾濕程度的包絡線等等。客服的態度也很好，還不收費，在Ps4上也運作良好。

手機打的，暫時說這麼多吧。就想想如果以上功能如果都讓程序自己實現需要多麻煩吧！還對程序的音頻知識都很高的要求。

題主可以下載一個fmod studio，打開裡面自帶的示例調調參數聽一聽，就知道這些東西的好處了。

以前4.x版本有個問題在Android音效始終要延遲1-2秒才播放出來，通常情況下沒問題，可是在有些時候很致命，必須要及時播放。當時在網上查喊自己用Java寫個介面unity去調用Java的播放不用unity的介面

用過一段時間的wwise，做以下幾個具體功能的時候比較方便：

1.當策劃需求一個聲音需要隨機播放多個隨機音源的其中一個時，例如腳步聲、普通攻擊聲，當這類聲音一直播放的都是同一個音源的時候，人會產生聽覺疲勞。如果使用wwise，客戶端只需要觸發事件就可以了，至於一個事件怎樣去隨機一個音效，就是策劃管的事了。

2.根據材質播放不同的聲音，例如挖掘土地和挖掘金屬、挖掘石塊要產生不同的音效，這個功能可以讓策劃配置不同材料的switch名，客戶端根據導表信息，自動設置switch，就會播放對應的音效。

3.聲音曲線RTPC（real time parameter control），x軸可以是距離、時間等，y軸可以是音量、音調等，曲線是可以拖動調整的，這就產生了一個可以可視化調節的對應關係，而這種對應關係就不需要程序去管了。

4.對全部聲音的狀態處理，例如在陸地上和水下，聽到的聲音效果應該是不同的，這個在wwise里可以進行比較簡單的設置。

5.對音源文件的內存優化，例如一段較長的背景音樂，可以設置只載入正在播放的那一小片段。

6.互動式音樂，類似dota那種，當戰鬥的時候播放戰鬥音樂，戰鬥結束切換為一般BGM，這是通過觸發器trigger實現的，客戶端只需要判斷切換戰鬥音樂的時機並觸發，wwise會自動根據策劃配置平滑過渡。

7.音效播放的各種效果，例如淡入淡出，播放之後停頓幾秒繼續播放，聲音播放幾秒之後慢慢變小等，都可以交由策劃配置，客戶端不用多寫代碼支持這些功能。

8.多平台支持，多語言支持。wwise支持多個平台，會根據平台不同輸出不同的bank文件（一類音源的打包小集合），並做相關優化。當遊戲的語音有多個國家語言版本的時候，wwise也能輕鬆設置。

9.性能監視。

10.動態混響，例如吃雞這樣的遊戲，在房間里打狙擊槍和在平地上打狙擊槍，由於房間內聲音會來回反射，所以混響效果應該是不同的。通過遊戲過程中，對RTPC實時變數的控制，可以達到此效果。

fmod沒用過不好說，wwise有多種效果，開關切換，運行時參數等可以提供全面的控制。音效同學在WWise的工程里編輯各種音效效果，然後生成soundbank到Unity工程里，程序員要做的就是調用api來載入卸載soundbank，播放音效，控制狀態開關和運行時參數等。

開發過程中經常遇到做出的效果和策劃要求略有偏差，然後經過溝通再次修改的問題，如果順利的話修改完就是策劃要的效果了，大家都滿意，就去開始下一項工作。但是很多情況是反覆修改好幾次最後才是策劃要的感覺，浪費不必要的時間。

使用音頻插件就可以做到效果完全由音效策劃控制，而不是程序控制，總之就是把最合適的工作交給最合適的人來做，大量減少溝通成本。

上個簡單粗暴的對比：

Unity音效系統音效插件

效果簡單種類豐富的合成器和效果器

效果由程序員控制效果由音效策劃控制

返工率高返工率低

程序員工作量大程序員工作量小