引子

大概是在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种可能的音乐处理方法：

1. User-Driven Static Transition——不受游戏状态影响的结果可预期的音乐段落处理方法
2. User-Driven Static Remixing——不受游戏状态影响的结果可预期的音乐混音处理方法
3. User-Driven Dynamic Transition——不受游戏状态影响的结果不可预期的音乐段落处理方法
4. User-Driven Dynamic Remixing——不受游戏状态影响的结果不可预期的音乐混音处理方法
5. Game-Driven (Static) Transition——受游戏状态影响的结果可预期的音乐段落处理方法
6. Game-Driven (Static) Remixing——受游戏状态影响的结果可预期的音乐混音处理方法
7. Game-Driven (Dynamic) Transition——受游戏状态影响的结果不可预期的音乐段落处理方法
8. 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中的重构；并在第三部分中展示利用计算机辅助作曲工具来辅助游戏音乐设计的案例，敬请期待！