關於動態音樂設計的思考-Part 1-設計分類學

大概是在2015年，我得到了自己第一份在遊戲公司的工作，然後偶然接觸到了Wwise（當時居然是通過一位美術總監同事的介紹……）。在那之前我的職業目標還是為遊戲譜寫音樂，儘管對互動音樂、音樂生成與演算法作曲已有興趣，但從未想到過這些東西就存在於從小便熱愛的視訊遊戲中……然而在我讀完Wwise互動音樂相關文件後，便意識到自己可能在從事世界上最棒的工作！但由於當時國內還不存在音樂設計師這樣的職位（可能現在也沒多少），並且還沒有多少遊戲公司充分意識到互動音樂的價值（也許現在已經好多了），我只能利用業餘或者自主加班的時間進行有關遊戲互動音樂的“地下研究”。

出於對遊戲互動音樂設計方法的更多可能性的好奇，我便開始了刷Google和Youtube的學習之旅……最初Youtube頻道Music By Kejero給了我非常多的啟發，他的系列視訊中對Vertical Techniques、Horizontal Techniques、Stingers、Transition Segments、Hybrid Techniques設計方法進行了系統地介紹，其中關於不同技術在敘事中作用的講解也使我開始思考技術與表達的關係。再之後的幾年中，我刷掉了能在Youtube上找到的討論遊戲互動音樂的所有視訊、讀掉了Audiokinetic Blog、DesigningMusicNow、Melodrive Blog這些網站上絕大多數與遊戲互動音樂相關的文章……這個過程讓我回顧了遊戲音樂的發展史——從蜂鳴器/Chiptune到自適應管絃樂，從硬體FM音源到演算法生成打擊樂（Intelligent Music Systems）；讓我瞭解到91年就存在的運用了Hybrid Techniques + Procedural Audio的天才引擎（Lucas Arts - iMuse）、瞭解到存在著開創性地將音訊與MIDI技術混合使用的瘋狂而巧妙的音樂設計（Get Even！）

現存學習材料存在的問題

學習的確是快樂的，然而在試圖將所學轉化為實踐的過程中我意識到幾個問題：

• 許多介紹遊戲互動音樂的材料，側重點都是受遊戲引擎驅動的音樂設計，在音訊引擎不受遊戲引擎驅動情況下的設計很少被提到；
• 遊戲中對於不同技術的使用總是“你中有我我中有你”，這也是為什麼會出現Hybrid這種稱呼（而Hybrid對Kejero與Olivier Deriviere來說可能指的又是極其不同的東西）；
• 處理方法的稱呼方式不固定——Vertical Techniques也被稱為Vertical Remixing、Layering、在某些地方甚至直接以Multitrack作為“Jargon”來代表這類技術；
• 通過混音技術實現的互動音樂創作手法沒有得到足夠的關注，而這恰恰是Olivier Deriviere的Hybrid（Audio+MIDI）方法中的複雜性所在，也是更加複雜的音樂設計可能性得以存在的基礎。
  

對策

Michael Sweet曾說 “…並不排除許多遊戲同時利用多種自適應音樂技術這一事實。但是，如果作為作曲家的我們要更好地為遊戲編寫音樂，那麼就應該為每種技術的使用組織一些通用準則。”

儘管藝術創作的可能性是無窮無盡的，但就像我們在日常工作中需要Shortcuts與工程模板——歸納總結處理方法以消除迷惑也像優化工作流程一樣，有助於我們降低試錯成本、儘快制定出貼合遊戲且可靠的音樂設計方案，並將更多的精力投入到精巧複雜的具體設計及實現當中，為此，我便嘗試制定了一套處理方法的分類標準，最初目的是指導自己的音樂設計實踐，在這裡分享給大家。

User Driven方法與Game Driven方法

首先，參考Wwise中定位及輔助傳送的概念，根據音樂表現是否受遊戲引擎狀態的影響，我將可能存在的音樂處理方法劃分為兩大類：User Driven方法與Game Driven方法。如此，獨立於遊戲引擎運轉的動態音樂機制便不會喪失該有的關注，從而能更好的被注意到和開發。

Static方法與Dynamic方法

然後，根據設計實現後結果是否能夠按預期執行，將音樂設計技術進一步區分為：Static方法與Dynamic方法。如此，便可對音樂設計問題中的線性與非線性進行更好的辨別，從而選擇合適的處理手段。

注：由於絕大多數情況下我們無法預料玩家在遊戲中的行為，所以採用Game Driven方法進行設計的遊戲音樂都可以被描述為“動態的”（Dynamic）；然而由於存在由實時過場動畫驅動不同音樂片段進行線性播放的設計，因此即便音樂未被渲染成一段音訊檔案，這種Game Driven的設計也算是“靜態的”（Static，所以Game Driven Static方法還是存在的）。然而因為這些都是遊戲驅動的，區別只在於遊戲驅動的過程是否是線性的，所以Game Driven方法的Static / Dynamic與否可不標明。

Mixing方法與Transition方法

Michael Sweet在他刊載於DesigningMusicNow的文章中將六種最常用的音樂設計方法分成了Vertical Remixing(Layering)與Horizontal Re-Sequencing兩大類。這也是我們通常討論遊戲互動音樂時會想到的最流行的技術術語。

就如Vertical Remixing（Layering）類方法的名稱及其本質一樣，無論具體使用的技術如何複雜，其實都可以被歸結為某種“與混音相關”的問題。

而Horizontal Re-Sequencing類方法實際上都是在處理音樂段落的切換與切換過程中的過渡的問題。因此，根據設計所處理的問題，我將處理方法進一步劃分為Mixing方法與Transition方法兩類。

小結

如此，根據上面提出的分類方法，我們將得到8種可能的音樂處理方法：

• User-Driven Static Transition——不受遊戲狀態影響的結果可預期的音樂段落處理方法
• User-Driven Static Remixing——不受遊戲狀態影響的結果可預期的音樂混音處理方法
• User-Driven Dynamic Transition——不受遊戲狀態影響的結果不可預期的音樂段落處理方法
• User-Driven Dynamic Remixing——不受遊戲狀態影響的結果不可預期的音樂混音處理方法
• Game-Driven (Static) Transition——受遊戲狀態影響的結果可預期的音樂段落處理方法
• Game-Driven (Static) Remixing——受遊戲狀態影響的結果可預期的音樂混音處理方法
• Game-Driven (Dynamic) Transition——受遊戲狀態影響的結果不可預期的音樂段落處理方法
• Game-Driven (Dynamic) Remixing——受遊戲狀態影響的結果不可預期的音樂混音處理方法。
  

注：因為這些都是遊戲驅動的，區別只在於遊戲驅動的過程是否是線性的，所以Game Driven方法的Static / Dynamic與否可不標明。

解析Interactive Music Hierarchy各結構單元的功能定位


在有了新的分類標準後，便需要將其用作理論來指導設計實踐，而我們進行實踐的工具便是Wwise。所以在實踐之前我們也需要從新的角度對工具進行理解。

接下來我將展示一張思維導圖，以便分享我對Wwise互動音樂系統結構的認識。

您可以在Github頁面 ( 連結：https://share.weiyun.com/5XNv7gf) 獲取該導圖的PNG檔案。


在上圖中，我使用了不同的顏色來標記各結構單元在音樂設計工作中所承擔的責任。

圖中紅色方塊代表”可用於User Driven類的處理方法“；藍色代表”可用於Game Driven類的處理方法“；紫色代表” 可用於User Driven與Game Driven兩類處理方法“。黃色代表Transition Manager（即Property-Transitions選項卡），由於其可被用於於各種型別的設計當中，與所採用的處理方法是User Driven還是Game Driven無關，故單獨列出。而綠色則代表自2019.1.0引入的Music Event功能，由於其為音樂設計的可能性帶來了極大的擴充，因此也單獨列出，下文中會對其進行詳述。

注：在進行標記前，我將要考慮使用的技術限制在各個結構單元的核心功能範圍內，這樣可以暫時避免引入過多的複雜性（通常這樣的複雜性都是與混音相關的）。您可以看到圖中存在一些包含Mixing欄位的很小的紫色方塊，它們都處於未展開的狀態，代表的便是引入對非Interactive Music Hierarchy核心功能的技術（如State/RTPC/Positioning/HDR等）考量後可能引出的處理方法。

巨集觀區域

Music Switch Container


首先，我們可以看到Music Switch Container的角色非常清晰：由於Music Switch Container Association Editor是Music Switch Container獨有的編輯視窗，加上其作用便是將單獨或組合的Game Sync——Switch / State與對應的音樂播放目標連線起來（而Transition Manager則可被用於為可能存在的過渡設定具體的表現方式），所以若要處理Game Driven Transition設計，首選結構單元便是Music Switch Container。

注：您可以看到， Music Switch Container可用的Game Sync——State與Switch儘管（在不考慮Scope問題的情況下）可用以實現相同的切換，但與State不同的是Switch的切換可由Game Parameter驅動（由此可引出不同的互動方式）。

Music Playlist Container


接下來來看Music Playlist Container，可以發現其角色也十分清晰：由於Music Playlist Container控制的是Playlist下Music Segment的播放次序，除了支援順序播放也支援隨機播放。所以我們可得出結論——Music Playlist Container的職責便是處理User Driven Static/Dynamic Transition的首選結構單元。

注：Sequence Continuous/Step用於線性的User Driven Static Transition設計，Random Continuous/Step用於非線性的User Driven Dynamic Transition設計。

小結


至此我們總結一下——可以說，Wwise互動音樂系統當中兩個比較大的結構單元都與解決Transition問題有關。有效利用Music Switch Container與Music Playlist Container，我們便已可以運用好User Driven Static/Dynamic Transition類及Game Driven (Static / Dynamic) Transition類處理方法。然而由於他們是互動音樂系統中最大的單元，這意味著不存在更上層的結構單元（硬說有的話大概是Bus）來將他們用作Remixing類處理方法中的某一個Layer，因此某些時候可能我們將不得不利用同一事件來同時播放多個此類單元來實現我們的設計。在本系列部落格第二部分當中我將介紹如何使用Wwise實現Terry Riley的 In C的音樂生成（其中便會用到這裡提到的處理方法）。

微觀區域


接下來我們將注意力轉向更微觀的區域，您可以看到結構單元——Music Segment、Music Track與Clip都被標記成了紫色，代表他們可以被用於User driven與Game Driven兩類處理方法；同時您可以看到，與Music Switch Container及Music Playlist Container不同，圖中使用紅色與藍色方框標記出的處理方法都歸屬於Remixing類處理方法而不是Transition類處理方法。由此我們可以直觀的看出，可能存在的音樂設計的複雜性不存在於上層結構單元而存在於細部，且都與混音問題相關。

Music Segment


首先，我們注意到Music Segment的Transition Manager分支被我標記成了藍色（並寫著Transition Manager：No），這是因為在點選Music Segment時我們無法在Property Editor中看到Transitions選項卡。

Music Segment可以說是Wwise互動音樂系統中最特殊的單元：首先，Music Segment具備Sync Point（Entry Cue與Exit Cue），其作用是溝通其子結構單元與父級結構單元，使運用Transition類處理的設計方法能夠正常運作；

其次，通過觀察Music Segment與Music Track的圖示我們可以知道Music Segment可以對多個Music Track進行混合，加之其直接子結構單元為Music Track，而對於Music Track來說不存在段落切換式的Transition，因此可以說Music Segment是User / Game Driven的Remixing處理方法的首選結構單元。

注：“傳統意義上”的縱向音樂設計方法（Game Driven Remixing）的首選運用場所便是Music Segment。

另外，由於Entry Cue/Exit Cue在Music Segment中進行設定，因此若要實現類似前衛搖滾的變化節奏，需要設定多個具有不同節拍設定或Entry Cue/Exit Cue設定的Music Segment。

Music Track


接下來看Music Track，可以看到與Music Segment類似，其也可被用於User Driven與Game Driven兩類Remixing處理方法。而與Music Segment不同的是，Music Track是通過改變所播放的內容來實現“混音”的變化。

其中，User Driven (Dynamic) Remixing方法可通過使用Random Step/Sequence Step Type Track來實現。

而Game Driven Remixing方法則通過Switch Type Track來實現。

我們可以將Music Track看作是互動音樂系統中的Voice，結合Transition Manager來實現音樂的“離散”Remixing處理（不同於以RTPC控制音量的“連續”Remixing處理）。

注：之所以Sequence Step無法實現Static型別的Remixing處理方法，是因為Sequence Step意味著每次該Music Track被播放，其播放內容會切換至下一個Sub-Track中的內容，因此實際上這種方法並不完全可控，僅切換次序是可設定的。

注：您可以看到， Music Track的Switch Type Track可用的Game Sync——State與Switch儘管（在不考慮Scope問題的情況下）可用以實現相同的切換，但與State不同的是Switch的切換可由Game Parameter驅動（由此可引出不同的互動方式）。

Clip


然後我們來看Clip，對於Audio Clip來說我們能做的都是User Driven Static Remixing處理，即對其進行簡單的音量 、LPF、HPF自動化編輯。而MIDI Clip則會引出極其豐富的處理方法（儘管這些處理方法可能都包含在User Driven Remixing類與Game Driven Remixing類當中），因為MIDI的發聲需要觸發Actor Mixer Hierarchy中的音訊物件，這些物件可以是聲源外掛也可以是樣本或包含樣本的結構，MIDI檔案包含的CC資訊也可被用作Game Parameter控制Switch/Blend Container從而形成User Driven的Game Driven Remixing。但自2019.1.0引入Music Event之後，這種“在User Driven與Game Driven處理方法之間的轉換”變得更加容易，對於作曲家來說，可使用的User Driven類音樂處理方法的數量被極大地擴大了。

注：由MIDI觸發的源、樣本或容器物件的混音無法通過互動音樂系統的結構單元進行，需在Actor Mixer Hierarchy中或Master Mixer Hierarchy中處理。

MIDI的優勢

為了更好的利用這些由Music Event帶來的新的可能性，我們需要將更多的注意力重新投向古老的MIDI技術。實際上MIDI與早期視訊遊戲音樂的發展密不可分。在其於80年代初發布之後便迅速被各個平臺接納成為計算機音樂開發的通用資訊交換協議。LucasArts的iMUSE早期便是基於MIDI開發的（儘管之後移除了MIDI模組）。然而在CD音源開始流行之後MIDI就逐漸變得不再是主流技術了。究其原因主要是作曲家無法絕對準確地預料MIDI音樂在玩裝潢置上播放的實際效果、以及MIDI在混音上的便利性無法與基於音訊的方法相媲美。

然而隨著Wwise MIDI音樂特性於2014年的引入（MIDI被納入了基於音訊的框架內）， MIDI的優勢正在重新被揭示出來：

1，MIDI體積小，且由於其並非音訊檔案，而更像是電子樂器使用的樂譜，因此通過擴充MIDI素材來增加音樂變化所需要的成本遠低於音訊，且遊戲中使用MIDI實現的音樂內容越多，這種優勢越明顯。Remedy音訊團隊於Wwise Tour 2018上關於Control的音樂設計的分享，便展示了依靠Python批量生成的大量具有不同節奏模式的MIDI素材，在對整體資料體積影響極小的情況下，獲得了近乎無線的聲響細節變化。同時由於生成與部署都可被自動化，他們還獲得了音樂節拍切換上的便利性。推而廣之，這種創造節奏變體的方法也可用於有音高的素材；

2，從音樂藝術構思角度看，同樣的MIDI素材驅動不同的音色可形成相差極大的聲響結果，某些情境下也可用以維持不同音響結果之間的內在聯絡（就像是動機）；

3，以模組合成器的使用思維來看，MIDI音符可作為Wwise內的“Envelop Trigger”使用來驅動實時合成，能提供相較音訊更有機的變化，您甚至可將大量音符密度不同的MIDI軌道用作不同速度的實時合成音樂的時鐘訊號（參見AK Blog上Olivier Deriviere的系列文章）；再進一步，Midi CC是很好的靜態自動化資訊源，使用者可以使用MIDI資料中的CC資料影響實時合成的引數來進行聲音設計，還可以用其影響遊戲的美術表現。

Music Event

在介紹過MIDI的優勢之後，我們來看2019.1.0起引入的Music Event特性。之所以將其放在最後講是因為MIDI Event可以說是比MIDI更強大的“音符”（MIDI還只能以Clip的形式存在）：它並不包含在Clip當中而是獨立存在，他能導致的不止某個音訊物件的播放——Event能做的幾乎所有事情，這個“音符”都能做到。我們可以使用Event來以各種方式控制聲音的播放、來混音、來控制聲音引擎，甚至可以來驅動動畫，Peter “PDX” Drescher便在最近的博文中介紹了Music Event與遊戲引擎中動畫的互動方式。


在上圖中我羅列了Event下包含的Action，並從音樂設計的視角對其用途進行了簡單的分類。在過去，Event是需要遊戲引擎傳送Game Call才能夠被觸發的，音樂設計師可以使用Music Callback / Custom Cue來實現類似的東西但是仍然需要Wwise之外的工作（也就意味著需要麻煩程式設計師）。然而現在他們完全可以自己在Wwise內完成那些工作，這意味著許多設計的實現效率提升，可能性被大大擴大。


以Music Switch Container為例，如果我們將使用RTPC與State對混音進行控制的複雜度納入分析範圍，便可從上圖中看到：因為Music Event的存在，Event Action中Set Game Parameter及Set State變得可用，導致音樂設計師可以利用Music Event以User Driven Static Remixing技術來改變混音（如果用其控制Sample&Hold也可以是Dynamic的，隨意）。


而回到Clip層面，Music Event對MIDI使用方法帶來的變化便是可以利用Music Event來精確控制Switch Container及Blend Container，由此音樂設計師完全可以在遊戲中像在DAW中使用Kontakt樂器一樣進行創作（想象一下將KeySwitch和Sample Morphing做到遊戲中去！）

本系列文章的第二部分將對我們在本章節中列出的八種音樂處理方法進行優劣比較，並對Mozart Dice Game與Terry Riley In C進行Wwise中的重構；並在第三部分中展示利用計算機輔助作曲工具來輔助遊戲音樂設計的案例，敬請期待！


聲音設計師/作曲家/音樂科技研究員，曾任職於育碧上海工作室，參與過《舞力全開》及《孤島驚魂》系列的聲音設計工作。現任Audiokinetic大中華區產品專家，愛好是探尋紙盆起伏與光柵明暗變化間的神祕聯絡。


作者：侯晨鐘
來源：Audiokinetic 部落格
地址：https://blog.audiokinetic.com/zh/about-dynamic-music-design-part-1-design-classification/