《硬核機甲》(Hardcore Mecha)的音訊設計
音訊專案背景
一個2d的橫版動作遊戲通常容易會給人一些類似“短小”“同人遊戲”“4399”這樣刻板印象,然而事實上《硬核機甲》擁有相當飽和的遊戲內容,我們製作了連貫流暢而又不重複的8小時單機流程,從開發規模來說即使和主機3A還有距離,它也不是一個很小的專案了。開發過程中出現的各式各樣的情況和問題對於一個小團隊來說也是相當複雜。
為了保證開發穩定進行,截止到上線,專案使用的引擎最新版本為Unity2017.4.27/Wwise 2017.2.9,本文接下來提到的內容也均會依照該版本。
音訊設計
讓Wwise 3D適應橫版遊戲的虛擬實時定位衰減系統設計
音訊組加入專案時遊戲還只有多人的部分,接入Wwise後,我們首先遇到的問題是:如何讓聲音有定位?我們應該實現怎麼樣的聲音定位?
為此我們參考了一些遊戲,並在我們專案中進行了一些實驗,發現雖然畫面中的各種內容聲源很樸素地從左到右擺放,但是我們遊戲會有頻繁的螢幕邊緣已經螢幕外的聲源,如果聲源還在可見區域內偏右/左但聲音就已經pan到了極左極右的位置的話,這種不自然的表現方式會導致玩家的注意力分散,喪失沉浸感。而另一方面,如果對可見區域外的聲源的聲像定位不明顯的話,則又會誤導玩家對發聲位置的判斷。
對於機甲遊戲,不同於其他題材的遊戲,遊戲中幾乎沒有常見的foley、普通大小體量的互動音效等元素。而充斥著規格相當大的機甲音效,如果按照通常的遊戲一樣按聲源的大小處理立體聲寬度,那麼其實基本上我們的遊戲都是點聲源了,機甲和機甲武器的厚重感會打折扣,為此我們希望音效能一定程度地展現立體聲寬度,但又不能破壞玩家對聲音的判斷。
Wwise2017版本中處理聲像定位有兩種方法:
- 使用2D positioning,在所有音效上掛上2Dpanner的RTPC,發聲時setRTPC來控制位置
- 使用3D positioning,開啟GameDefine,裡用listener和聲源的關係確定定位
經過分析,我們判斷第一種方法雖然比較直觀,但沒有辦法將立體聲的聲源自由的處理成點狀或者塊狀,並且這種方法需要給每一個音效傳RTPC手動運算pan的位置,在每一幀進行快速重新整理,在發聲數巨大的情況下這樣也會給程式部門的運算帶來額外的壓力。
使用第2種方法可以直接裡用Unity的Transport來藉助Wwise進行運算定位,但listener位置的處理以及它跟2d的邊界管理就會成為一個問題。
最終經過考慮後,我們還是決定使用3D來進行製作。
於是首先整理下需求:
- 我們希望沿用Wwise的3d定位和衰減功能來讓2d橫版動作遊戲的各種運動聲音平滑的進行聲像變化,這樣可以獲得較為順暢的定位體驗,同時比較好的控制開發設計成本和效能開銷。
- 在畫內時,為了體現機甲的體量,在畫內時適當地讓聲源的表現效果是塊狀的
- 希望聲源離開螢幕後能有一定程度的衰減和濾波效果,能清晰地辨識到左右畫外
我們遊戲使用了我們進行定製的ProCamera2D外掛來管理鏡頭和渲染流程,這在賦予遊戲多變的鏡頭和效能優化的同時,也導致專案中沒有像常規3d引擎思路下的camera和z軸關係,所有內容都在一個平面上。而畫面內容的變化時也沒有實際上的camera物體物件的遠近運動,是單純地改變鏡頭。的CameraSize來實現畫面內容的變化。
在這樣的環境下,ProCamera2D只有一個鎖定在畫面中心的Object,如果直接把listener丟在這個所謂的“Camera”上,就會出現所有的聲音都在極左極右的現象。
於是經過討論與思考,我們為listener單獨建立了gameObject,嘗試讓他單獨處在z軸的一個相對位置,並讓他跟隨畫面中心的xy座標位置。這樣一來,Wwise 的3D 遊戲定義定位功能就可以正常工作。但這樣一來,如圖所示,Listener到聲源的位置關係就變成了一個三角形的斜邊,想實現“聲音左右出屏變小”的話,3D 衰減設定中的max Distance就不在是線性關係,衰減曲線的設計和除錯就變得複雜了。為了解決這樣的問題我們使用了一套方案:
如圖,假設該圖中LR為玩家的橫版畫面的俯檢視,L為左邊界點R為右邊界點,C為中心。設C到R為X,實際上,我們定義的這個畫面長度LR是會放大縮小的,X的值也就會隨著劇情的發展或玩家的動作而變化。
則Listener到畫面邊界的BorderDistance=√(x?+y?),這個也就是畫面邊界的聲源到Listener的距離,由於Wwise不能在遊戲中通過RTPC實時調整attenuation的Max Distance,只能依靠程式來修改整個衰減的Scale,引出更多的計算。所以我們就直接在我們在程式中鎖定這個BorderDistance的值,當畫面拉近時X變小,那麼只要反算出y的值(也就是Listener與中心C的距離),並根據y的值把實際的listener擺在對應的位置,即可在橫軸上得到正確的衰減效果。
這樣一來,不管鏡頭如何變化運動,玩家的Listener總是能在基於畫面大小和固定的BorderDistance所演算出的位置,之後只要保持讓3D的音效衰減設定的MaxDistance和BorderDistance相等,調整這個BorderDistance(MaxDistance)即可聽到平滑的左右pan的效果。以此就可以進入下一步調整音量和頻響上的衰減。
然而這裡有兩個問題,一個是這樣一來衰減的範圍對遊戲的截面是一個弧形,如果中心線的範圍正確的話,四個角的音效會到Wwise Attenuation的極限,另一個是一旦超過左右邊界,聲音也會到Wwise Attenuation極限。對於我們遊戲,四個角都有一些UI,不會在這些鏡頭死角發生一些重要事件,但在戰鬥中聲音毫無疑問是會經過這些地方的。
所以接下來我們希望在四個角或者已經出螢幕的聲源在一定範圍內能有一定的衰減,並且聲像定位變化能更加明顯,實現的方法也較為簡單:提高wwise的max Distance的值,讓他比程式的定值BorderDistance大一些,然後針對距離超出borderDistance的聲音設計Volume、LPF/HPF等衰減曲線引數。注意這裡除了動了衰減曲線之外,還新增了Spread的曲線,這樣立體聲寬度較大的聲音在畫內時,能擁有較為飽滿、“塊狀”的聲音表現力。
目前較新的版本中,Wwise使用了是否與Listener 關聯Routing來代替的3d/2d的設計,position/orientation也可以混合使用,理解上更加直觀化了,但如果用在我們專案中原理上並沒有太大變化。我們因為種種原因沒有機會使用該版本。
上文所述對於通用的機甲運動音效的情況,事實上對於各種各樣的武器子彈、射擊、場景互動物體等等,我們還配置了幾種不同的衰減ShareSet,用於應對各式各樣的狀況。
比如圖中的較為長距離的大規模光束武器,我們用了Maxdistance為5倍於普通機甲音效(BorderDistance)的長衰減,以實現讓它在螢幕外很遠的地方以極左右的聲像給人預警。也會有一些場景元素比如火焰為了不過度干擾玩家等使用了較短的衰減,離開螢幕中心附近時很快開始變小。對於不同的子彈擊中的物理效果,也都應用了不同的衰減模板,通常光束類會比子彈類遠一些。MaxDistance上,都是首先大於listener到畫面中心C的距離,然後向外定義各種東西的衰減長度。
塑造物理世界效果
對於硬核機甲這款遊戲,機甲的型別、武器以及子彈的型別眾多,這些各種各樣的元素涉及了大量的材質,這些材質大量互動就會產生數量型別繁雜的音效和特效。Wwise的Switch功能可以很好的管理這些內容,但為了與特效系統的進一步整合,我們沒有采用在Wwise中設定,而是在unity中設計了一套“物質效果系統(MatterEffect System)”以統一管理特效和音效。
該系統中,我們把材質物件分為Platform/Mecha/Bullet,按這三個型別互相之間的互動來配置腳步聲、跳躍飛行落地、子彈擊中玩家/場景/子彈等,整理為子彈對角色、子彈對子彈、子彈對場景、角色對場景四類、然後將音效使用Wwise Type介面和美術特效、震屏、手柄振動和鏡頭特效組織在一起進行配置。為了快速完成大量配置,我們還做了一些類似複製、批量編輯之類的編輯器功能上的優化。
相對應的,在Wwise中我們也使用了接近的結構來組織混音,下文會講。
另外,機甲和場景接觸的方法並不是只有移動和跳躍,為了豐富遊戲的音效細節表現,機甲在接近地面時我們還設計了滑行揚塵的音效,這類音效我們歸類為Tracking Moving Sound。我們使用了一個RTPC和揚塵的Blend Contener音效進行繫結,在特定機甲與特定材質的地面(一般是土/沙子)等距離較近並具有一定的相對速度時,會按照其滑行速度播放相應響度、樣本厚度的聲音。我們定義這個RTPC引數為speed,並且這個speed引數也和相應的特效大小按照一定的引數比例運算在一起。我們把它和前面的物質系統相結合處理了聲音的效果。
這個引數還影響了部分不是用腳步而是使用滑行來移動的角色,我們為他們的移動聲音設計了engine sound,把玩家的搖桿x軸偏移程度或者AI敵人當前的移動狀態dynamic值(一個相對值,可以理解為AI的目標速度或者“油門”)定義為locomotion speed,並將該引數對映到RTPC來控制引擎的聲音強度,而實際移動的speed則影響引擎聲音的渾厚程度,通過blend container的不同軌道來實現。
我們在實際實現並測試該設計時,還發現這些數值的跳變比較激烈,玩家撥動搖桿的速度很快、角色的移動也會在近戰對抗中產生快速的變化,這裡我為所有涉及的RTPC都設定了一定的slew rate,讓它們在程式傳入引數時的變化有一定的漸變,模仿物理引擎的變速阻尼感,並取得了較好的效果。
營造沉浸感的細節
硬核機甲單機模式中擁有各式各樣風格各異的場景、關卡,如漫天沙塵的火星礦坑,深夜中的營地、聯通水下的祕密工廠,宇宙空間平臺等等,這些關卡通過劇情、演出設計都給人帶來了強烈的戰爭臨場感。因此,音訊上我們也必須儘可能的在這些關卡中找到元素,利用Wwise設計一些實時的表現,主動塑造一些變化來滿足玩家對於沉浸體驗的需求。
這裡來舉幾個例子:第二章的玩家在雨夜潛入時,我們也簡單引入了潛入遊戲的一些常見的設計:我們根據玩家所處的“正常探索/被發現”的狀態創作了兩種對應phase的音樂,使用動態音樂系統切換,而當玩家被探照燈發現時,切換音樂的同時也使用了低通濾波器壓制音效,配合一個緊張的音樂片段來刺激玩家,我們還刻意來為場景畫面上製作了雨,雨聲提供了豐富的中高頻細節,而這種設計是為了迎合玩家躲進掩體時,將音樂和聲音都用濾波器在bus上切掉500Hz以上的內容設計,以此來進一步塑造玩家神出鬼沒的體驗效果。
潛入關與水下關
第三章中玩家一上來掉入了一個巨大的水庫,機體在水中重新啟動向其中深入探索。我們同樣採用了“先設計中高頻細節,再切掉中高頻細節”的策略。這次將玩家到水面的距離對映為RTPC,掛在音效bus的均衡上,當玩家深入水中時,中高頻會隨著高度愈發壓低,而出水的時候中高頻的迅速恢復加上水花聲本身的高頻,提供類似人類音效的體驗。
第五章在一個大型天空平臺中,玩家會頻繁在室內、室外穿越,我們為此設計了一個RTPC區域,用於標識在一個trigger體內定向運動時,根據玩家在區域內X軸/y軸的位置對映變數到一個RTPC值,以此來切換室外高空強風和戰場的環境聲和室內的環境聲以及混響的比例,塑造室內的擋風效果。
硬核機甲的九章單機遊戲當中,每一章我們都找到了一些這樣的點來運用Wwise的互動音訊功能來主動營造聲音變化,提升玩家的沉浸感。
聲音設計
硬核機甲在聲音設計上追求真實聲音和日式動畫音效之間的一種調和,我們希望一方面儘可能在聲音內容上飽滿豐富,另一方面又想追求舊合成器、擬音調出來的部分舊式感覺。為此我們引入了一些噪聲合成調製,和取樣合成器的運用,同時也採用了大量的實錄樣本來進行製作。
混音
結構組建
遊戲的兩種模式雖然都使用了接近的音效,但實際上,遊戲的戰局和目的截然不同,聲音結構組織的出發點也截然不同。
對於單人模式,玩家所發出的聲音和其他聲音的邏輯關係是完全區分開的,聲音的中心通常集中在主角身上,場景中有大量的敵人,也具有環境、音樂、音效等角色扮演遊戲常見的各類要素,樣本管理上應按照這些元素的分配來處理。
而對於多人模式,玩家著眼於快節奏的戰鬥,時刻關注著戰局中其他人的狀況,一個音效可以準確代表它所表達的角色,引導玩家思考應對的方案。應該按照角色來進行分配。
帶著這樣的思路我們觸發,混音上,我們圍繞著單機關卡部分和多人模式部分的聽覺側重點,戰鬥狀況,樣本的型別上的區別,將音效劃分成兩部分來進行混音,為他們搭建了分開的Actor-Mixer來進行組織。
結構上,我們基本上是以Unity專案內的各類程式系統和資源結構進行組建,這樣能促使工程儘可能地貼合遊戲的需求。
對於單人模式,我們面對的是線性故事流程中大量的武器,各式各樣的場景物體和可互動物體,相對複雜豐富的物質系統,我們以這些不同的元素為中心進行整理,把機甲按角色運動動畫、場景互動、射擊武器、子彈的材質和打擊物件、關卡里的各種內容等進行分離。並圍繞著遊戲專案中的各種系統為這些引數分別進行了混音上的處理。
而對於多人部分,我們則是按機體角色和對應的技能、武器進行的分類,並依照多人的衰減模式以及可能出現的分屏模式進行了音效管理。
動態混音與混音重心
對於單機模式,玩家所面對的始終是一個向前探索體驗故事的流程,設計師需要留意玩家的注意力的聚焦點,針對性地進行設計。在我們的單機關卡,拋除掉UI玩家對聲音的注意力首先在敘事線索上,其次到場景中關鍵的敵人(比如boss,精英敵人),然後到玩家自身的格鬥、射擊動作以及其對敵人的所造成的傷害反饋等等,最後到場景中的其他敵人,環境等等聲音。
分析了遊戲的相關行為後,混音首先圍繞著這一點進行音量分佈即可,分類豐富的聲音元素的混音變得簡單了不少。除了直接在專案中調整各個bus/ActorMixer的音量之外,我們還設計了一些RTPC來協調不同型別音效之間的關係,比如將部分較為主要的爆炸樣本或大規模運動的音效上新增Wwise Meter外掛並利用匯出值來對音樂音效進行側鏈壓縮,並使用HDR來自動處理音量之間的關係,這些方式類似於ducking,但使用上會更加靈活,當優先順序更高的的聲音出現時,其他聲音會變小為其讓路。
然而實際上,僅靠這些系統性的設計依然無法讓關卡流程的聲音表現豐富,為此我們還單獨建立並使用了一些RTPC/State當推子來在遊戲中根據故事流程實時調整畫面中出現的元素的比例,這些處理的目的在於放大玩家當前所需要注意的內容的存在感,突破固有的結構。併為玩家帶來更為舒適的體驗。
例如這裡是關卡中出現的第一個機甲敵人,雖然和後面百上千的敵人一樣都是雜兵,但我們建立了用state單獨在這裡放大了他的運動和開火音效,強化它作為第一個機甲敵人的存在感。此後也為其他和劇情相關的角色進行了單獨處理。
第六章的兩個STG關卡中,子彈、敵人的出現方式和之前的關卡大相徑庭,之前數量較少的物體、武器及其子彈會大量頻繁的出現,敵人數量也會在屏內迅速增多,為此我們運用State和Switch Container的組合來響應材質系統的引數,將部分樣本音量縮小、應用單獨的壓縮器並做發生數限制。
硬核機甲的特色玩法之一是玩家有時可以脫出機甲戰鬥,也會有很多人類和機甲同時出現,然而機甲的大小自然大於人,如果人的聲音在響度上和比例上和機甲相同,就會顯得十分跳戲,經過思考我們決定處理成玩家在駕駛員脫出狀態下,聽人類的聲音比例會大一些,反之在駕駛機甲時聽人類的聲音會小一些。
關於響度、動態範圍、輸出裝置協調的思考與處理
我們遊戲的發行會同時登陸主機平臺和PC平臺。對於這兩類平臺玩家的音響輸出裝置多種多樣,主機平臺主要以家庭音響/電視自帶音響為主,部分玩家也會採用耳機來遊玩。而PC平臺則有家用音響,耳機、顯示器音響,筆記本音響外放等多種多樣的裝置。而這兩類平臺上不僅僅是裝置有區別,玩家主要遊玩的遊戲也有不小的區別,我們需要儘可能地滿足各式各樣裝置的需求。
首先在平臺區別上,對於PS平臺,索尼在TRC稽核時給出了指示性的響度參考:遊戲通篇流程的平均響度規劃在-24dB LKFS左右,該響度事實上和電影行業所使用的參考標準相同,我們使用Wwise的Loudness表和把音訊訊號錄製並接入到DAW測試後,遵照該響度指示調整了各Bus/Actor-Mixer的大小使整體響度趨近於該值。但對於pc遊戲尤其是獨立遊戲,這個平均響度有點過小了,PC玩家使用的裝置更不確定,但類似顯示器/筆記本自帶音響通常輸出能力較低,聲音輸出過小會限制遊戲的表現力,為了協調這種差異,我們給pc定製了不同的混音策略,PC端的均衡響度會提到-18dB LUFS左右、動態範圍也會稍小一些。
動態範圍的改變上不只是輸出裝置響度之間的協調,事實上,我們還針對使用不同播放裝置和不同條件的玩家採取了不同的策略來進行設計,並將其開放為一個設定引數來讓允許玩家進行調整。我們希望通過設計來實現在高動態範圍模式下,子彈擦過/機甲的小關節運動/背景環境元素之類的聲音內容小一些,而主要的機甲運動、近戰格鬥等內容的聲音等在混音策略中重要的東西則大一些,以此拉出一個符合我們遊戲混音策略的大動態範圍。低動態範圍則反之。
為此我們使用了一個Dynamic Range的RTPC來控制整個HDR的threshold,但是一個機械自動的HDR並不能完全準確地判斷出需要放大/縮小的聲音有哪些,於是我將該RTPC借題發揮掛在了各式各樣分類的Actor-Mixer/音效上來控制其Voice Volume。詳細地依照前面的混音策略來擴大各個元素之間的音量差異來塑造動態範圍。(大致直觀點)
將Dynamic Range引數整理後,我們開放了兩個設定供玩家調整,玩家可以選擇播放裝置來調整動態範圍。考慮到玩家在耳機模式下底噪較小,我將耳機模式設計為比音響模式的Dynamic Range稍大一些,然後開放三個動態範圍供玩家自行設定。這也是音訊選項相對比較多樣化的主機遊戲常見的做法之一。
另外,播放裝置的調整也跟立體聲寬度有關,這個設定同時會影響Wwise的Channel Configuration和Panning rule(Speaker或者headphone的角度控制)。
牽扯到動態範圍調整策略的聲音元素
Ducking與Side-Chain
上文各個步驟中提到了大量的聲音型別及如何利用並讓混音儘可能地將各種元素在音量比例上拉開,然而遊戲依然存在聲音太過繁雜的問題,戰局混亂時,重要的機體爆炸/劇情元素運動/臺詞出現時,渾濁的戰鬥音效依然在干擾這些關鍵聲音的敘事表現。一味的提高這些聲音的音量只會破壞聲音的平衡,嚴重的時候會嚇到玩家。
於是為了突出敘事中心,我們需要強化這些音效,首先想到的當然是為關鍵音效和語音新增Ducking。
然後很快出現了一些問題:製作人不喜歡Ducking的機械降低效果...
這其實是要求混音處理的更加自然一些,在讓玩家清晰地辨識到敘事物件的同時,更不讓玩家聽出明顯的系統處理效果。為此我們改用Side-Chain的方法來進行處理,首先我們使用Wwise Meter匯出了部分爆炸音效和過場的音量值為RTPC,並用其反過來微調SFX的音量補正值。而對於臺詞我們使用了更加複雜一些的處理:我們在整理語音樣本時測量了主角、隊友、宿敵角色等幾個關鍵角色說話的大致基頻,每個角色使用的的頻點不同,將這幾個角色的mixer的音量用meter匯出到一個RTPC,並在SFX的bus上使用eq效果器在對應的頻段使用一個q值較低的eq引入該RTPC值,對這些頻段的音量進行衰減。
分屏問題
硬核專案還有一個特別的問題:本地分屏模式
這是一款支援本地四人分屏對戰的遊戲,這裡看起來似乎只是擺了四個攝像機對著四個人拍,然而事實上,我們遊戲的四分屏都有相應的邏輯聲源,如果簡單的將攝像機和listener繫結,螢幕上的聲音最多會發生十六次...這是一個發聲數邏輯跟遊戲邏輯混淆在一起的問題,不能簡單地使用playback limiter來解決,必須加以處理。
首先按照原有的衰減模式的話,幾個玩家是否在觀測同一個聲音會導致這個音效產生劇烈的大小變化,為了協調該問題我在兩人以上的分屏模式關掉非操作物體(子彈、爆炸效果等)的3D衰減,然後在各個bus上根據玩家的數量對各actor-mixer進行了下壓。每多一個玩家,各個mixer向下壓6dB左右,不同的元素會有少量的差異。
原文:https://blog.audiokinetic.com/zh/sound-design-of-hardcore-mecha/
相關文章
- 《硬核機甲》(Hardcore Mecha)的音訊設計 - Part2音訊
- 《硬核機甲》製作人自述獨立遊戲開發者之路遊戲開發
- 光明網:《硬核機甲》打破國際主機遊戲行業偏見遊戲行業
- iOS音訊程式設計之實時語音通訊(對講機功能)iOS音訊程式設計
- 高效的音訊製作與槍和車的音訊設計方案音訊
- 音訊設計經驗分享:聲音功能的設計與創意表現音訊
- LinuxCOSS音訊程式設計Linux音訊程式設計
- 展望遊戲音訊設計的發展方向遊戲音訊
- linux音訊程式設計指南Linux音訊程式設計
- 計算機硬核知識大全計算機
- 國產遊戲《硬核機甲》開發者訪談:熱愛與堅持澆灌出的夢想之花遊戲
- 基於《十三機兵防衛圈》的音訊整合設計理念及工程分享音訊
- Linux下的OSS音訊介面程式設計(轉)Linux音訊程式設計
- 【秒懂音視訊開發】09_音訊錄製02_程式設計音訊程式設計
- 硬核!程式設計師延壽指南程式設計師
- 【梟·音訊】聲隨意動——淺談《暗影火炬城》聲音設計音訊
- 05:音樂響起來!遊戲主角穿上馬甲啦#python遊戲程式設計#紅傘傘遊戲Python程式設計
- 乾貨丨遊戲音訊與聲音設計相關書籍推薦遊戲音訊
- 如何利用 AVFoundation 設計一個通用穩定的音視訊框架?框架
- 雷亞新作《Binary Gods》概念視訊公開 機甲動作遊戲Go遊戲
- 榮獲“休閒/社交遊戲類最佳聲音設計獎” 《使命召喚手遊》是如何做空間音訊設計的?遊戲音訊
- 程式設計師需要了解的硬核知識之磁碟程式設計師
- 程式設計師需要了解的硬核知識之CPU程式設計師
- 音視訊--音訊入門音訊
- 音視訊–音訊入門音訊
- CRI新音訊工作室設立、強化音訊(音樂、聲優等)製作業務音訊
- MT6739+MT6357音訊設計資料參考音訊
- Ganker機器人:手機遙控的機甲機器人機器人
- 音訊_錄音音訊
- 全網最硬核解讀計算機啟動原理計算機
- 全網最硬核講解計算機啟動流程計算機
- 如何為實時音視訊設計小且優的深度學習模型?深度學習模型
- win10 主機後置音訊沒聲音怎麼辦_win10主機背部音訊輸出無聲音解決方法Win10音訊
- Kotlin的魔能機甲——KtArmor(三)Kotlin
- Kotlin的魔能機甲——KtArmor(一)Kotlin
- HTML的音訊和視訊HTML音訊
- ijkplayer 音視訊同步時間的計算
- 從 UI 設計角度探討如何製作 UI 音訊 - Part 1UI音訊