淺析游戲中的音頻GameObject管理

1、淺析游戲中的音頻GameObject管理GameObject是使用Wwise進行音頻設(shè)計的基礎(chǔ)理念，從Wwise基礎(chǔ)功能的使用（尤其是Profiling），到使用WwiseSDK開發(fā)都會涉及這一概念。筆者在日常工作中遇到過不少因為音頻GameObject管理不善而引發(fā)的問題。故而嘗試對音頻GameObject的注冊與管理方法進行一定的梳理。首先我們來介紹一下關(guān)于本問題的相關(guān)背景和一些基礎(chǔ)概念。1、什么是GameObject？首先我們來統(tǒng)一一下概念。為了避免大家和廣義上游戲引擎中的GameObject以及Object-Based Mixing等概念相混淆，此處的定義以Wwise引擎中關(guān)于Game

2、Object的定義為準(zhǔn)：同時為了與Wwise的界面及文檔統(tǒng)一，后文中也統(tǒng)一使用（Wwise中的）GameObject這一名稱。2、為什么要進行音頻對象管理？由上文可知，GameObject是Wwise中的核心概念Wwise對音頻的管理都是基于管理GameObject來實現(xiàn)的?？梢哉f，在使用Wwise的情況下，游戲中任何聲音的播放都離不開GameObject（無論聲音是2D/3D）。若音頻GameObject管理不善，會導(dǎo)致各種問題輕則Wwise內(nèi)的功能異?；蚴В貏t在游戲引擎開發(fā)層面留下隱患。3、以GameObject為單位管理音頻是Wwise獨有的么？有什么特別之處？以GameObject

3、為單位（Object-based）管理音頻并非Wwise獨有，也存在其他音頻引擎（或音頻管理器實現(xiàn)）支持這一管理方式。Wwise Event、GameObject與UE Component的關(guān)系梳理為了方便理解GameObject的重要性及其工作原理，我們以一個最簡單的藍(lán)圖接口實現(xiàn)為例，看一下GameObject是如何在代碼層面被創(chuàng)建和引用的。由于Audiokinetic（Wwise的開發(fā)公司）官方維護有一套功能豐富的Unreal引擎集成，因此Unreal引擎集成當(dāng)中對于Wwise的SDK的用法具有一定的代表性，故而筆者在此處以PostEvent藍(lán)圖接口為例來論述。以下截圖為Unreal中Po

4、stEvent藍(lán)圖節(jié)點的C+代碼：Unreal中Postevent藍(lán)圖節(jié)點定義：該段代碼對應(yīng)該藍(lán)圖界面：該藍(lán)圖節(jié)點上AkEvent和Actor兩個輸入點必須連入變量或具體的值，否則將會在編譯時報錯。代碼邏輯簡單講就是：運行PostEvent節(jié)點時會給指定Actor對象的RootComponent層級附加AkComponent附加AkComponent的過程，首先遍歷當(dāng)前Actor的子級:如果已有AkComponent則直接啟動，如果沒有，那就新建一個AkComponent：然后AkComponent會通過類別轉(zhuǎn)換和Wwise內(nèi)的GameObject進行強綁定。所以，每個Actor播放Wwise

5、的聲音時，AkComponent必須存在。AkComponent的作用：AkComponent就是存在與UE中的Wwise專用的GameObject（的容器），其可以調(diào)用到以下函數(shù)：純看代碼可能不方便部分沒有代碼基礎(chǔ)的同學(xué)理解相關(guān)概念。接下來我們換一個更加通俗易懂的方法來描述下這個邏輯：游戲引擎使用音頻中間件播放聲音的邏輯是這樣的：總結(jié)（第一節(jié)）（Wwise中的）GameObject的數(shù)據(jù)來源是游戲引擎中的AkComponent，且該來源不可或缺。（數(shù)據(jù)可能包括方位、轉(zhuǎn)向、GameSync等等信息。）可以說每個聲音的播放都指向了一個目標(biāo)對象AkComponent。Wwise會為目標(biāo)對象注冊一個

6、與之匹配的（Wwise中的）GameObject來承載聲音，其基礎(chǔ)屬性全部從AkComponent繼承。所有的以AkComponent為目標(biāo)對象Post的Event都是以該（Wwise中的）GameObject為目標(biāo)的。如果使用一個感性的說法：（Wwise中的）GameObject就是某個人（AkComponent）在聲音世界的分身，負(fù)責(zé)承載所有指向這個人的事件。另外，（Wwise中的）GameObject除可依據(jù)AkComponent被注冊，也可被解注冊。明白了這些以后我們可以做什么呢？1、什么是Event-based音頻管理早期的游戲音頻中間件或者小體量游戲的音頻管理器實現(xiàn)基本都是以Eve

7、nt-based的理念來管理游戲中的音頻的。而現(xiàn)如今，通常游戲中的每一個聲音都是一個獨立的對象。偶爾會有一些接手音頻開發(fā)的同學(xué)在缺乏考慮的情況下選擇簡單粗暴的方式來實現(xiàn)音頻播放的管理與控制：我在本文中將他們統(tǒng)稱為基于事件的（Event-based）音頻管理。之所以這樣劃分，是因為他們在實現(xiàn)時通常只考慮了聲音的觸發(fā)，并沒有考慮到聲音在觸發(fā)后進一步進行控制的必要和復(fù)雜性。盡管上述對象的創(chuàng)建和管理模式存在一定的合理性，但它們肯定是不能滿足所有開發(fā)需求的。先來看一下第一種方式（一個事件伴隨一個隨機對象）：稍有編程功底的同學(xué)們都知道，游戲中對象的創(chuàng)建和銷毀是需要占用系統(tǒng)資源的，低頻率事件可以使用該模式，

8、如果是高頻觸發(fā)事件，那么將會在短時間內(nèi)大量的創(chuàng)建和銷毀對象，會導(dǎo)致不必要的系統(tǒng)消耗這是Event-based模式在性能消耗方面可能存在的隱患。當(dāng)然某些場合可以采取創(chuàng)建對象池的思路來優(yōu)化，但并不是所有聲音的播放都適合指派到隨機的對象上。如果我們的游戲中存在多個對象同時觸發(fā)相同聲音的情況，那么Event-based模式將很難精細(xì)的管理這些聲音，因為所有的Event都是相互獨立的，音頻引擎無法區(qū)分哪些Event屬于游戲里的哪個對象。這導(dǎo)致在進行發(fā)聲數(shù)上限等音頻管理時就只能進行全局管理，也就是只能使用Wwise中的Global模式進行管理。再來看一下第二種方式（大量事件指向同一個對象）：通常在游戲?qū)ωS

9、富的聲音設(shè)計提出需求的情況下，設(shè)計師本身也要將性能的控制考量進去。而將所有聲音分配至同一個游戲?qū)ο蟮淖龇?，會?dǎo)致以實際游戲內(nèi)對象為單位的更細(xì)致的聲音并發(fā)控制無法實現(xiàn)（與第一種方式一樣會遇到這個問題）。若此時還對此同一個音頻對象的聲音并發(fā)量設(shè)置了上限（Global），則可能導(dǎo)致聲音被隨機誤傷，進而產(chǎn)生不合理的聽感。而若要解決聲音被誤傷的問題，就需要解除聲音并發(fā)量上的限制，而這又會導(dǎo)致較大的性能消耗?？偨Y(jié)（第二節(jié)）Event-based音頻管理是將GameObject視為Event的附屬物，為每個聲音事件匹配一個GameObject的做法。而Object-based音頻管理則是將Event視為Ga

10、meobject的附屬物，先注冊和游戲中對象對應(yīng)的（Wwise中的）GameObject，然后Event作為子項繼承Gameobject的相關(guān)信息的做法。為了更方便大家理解，我們此處直接使用一些工作中可能會接觸到的案例來進行分析：假定我們當(dāng)前正在開發(fā)的游戲中并沒有加入Object-based的理念，依然基于Event-based的理念來觸發(fā)和管理聲音，那么Wwise將不會正確接收和游戲內(nèi)對象對應(yīng)的GameObject信息，而是盲目的為每個音頻事件獨立生成GameObject。那么我們在使用Wwise時可能會遇到以下問題：1、Wwise內(nèi)所有和GameObject相關(guān)的功能全部失效或表現(xiàn)異常具體

11、會如何混亂，參見下圖：2、產(chǎn)生不必要的系統(tǒng)消耗以玩家的腳步為例：再以一輛車為例：若車的引擎、胎噪、風(fēng)噪彼此是獨立事件觸發(fā)的，它們都需要讀取車輛的車速。雖然這個消耗可能依然不算大，但是這也是一個不健康的狀態(tài)。3、針對GameObject設(shè)置的插件反復(fù)實例化這個前文已經(jīng)提到過一次，因為每個聲音都是一個獨立的object，所以每有一個聲音都會實例化一個新的插件，每個插件都有自己獨立的運行參數(shù)，而不是從屬于同一個GameObject的插件擁有相同的參數(shù)。4、限制了虛實例技術(shù)的使用因為不能獨立注冊和銷毀GameObject，也沒有辦法通過讓多個發(fā)出相同聲音的發(fā)聲體只實例化其中一個的方式來減少系統(tǒng)消耗，所

12、有的發(fā)聲體都將是真實實例化的?？偨Y(jié)（第三節(jié)）如果大家在工作中遇到了類似以上所述的情況，可以嘗試查詢一下游戲內(nèi)針對音頻的GameObject的創(chuàng)建和注銷機制是否正常。有可能有助于大家定位問題產(chǎn)生的原因。1、游戲開發(fā)初期應(yīng)當(dāng)規(guī)劃音頻對象池，對于可能高頻重復(fù)觸發(fā)的聲音事件采用對象池技術(shù)管理，甚至所有的音頻對象都采用對象池技術(shù)進行管理。2、游戲開發(fā)時除了規(guī)劃聲音的觸發(fā)和停止機制以外，還要注意規(guī)劃聲音所屬GameObject的創(chuàng)建和銷毀（引用和解引用）時機。3、游戲引擎的音頻接口開發(fā)時應(yīng)注意盡量保持和Wwise官方SDK的參數(shù)設(shè)置保持統(tǒng)一，必要的時候給Wwise開發(fā)獨立的音頻接口。4、進行音頻中間件的更換或升級時應(yīng)注意新舊中間件SDK的兼容度。如果兼容度低，升級過程中可能需要開發(fā)新的音頻接口和同時修改聲音的掛接邏輯。以上就是截止目前我們對于音頻Ga