在本文中，我将从个人观点出发简要阐述使用 Wwise 的几点好处。尤其是在制作高预算游戏时，它的优势会更加明显。 

我们先来总结一下使用音频中间件的普遍好处：

• 提升工程的声音品质。

• 提高资源的利用效率。

• 减轻编程的工作负荷。

在玩游戏的时候，音频体验占了一半。游戏中音频的作用可不只是触发声音那么简单。遗憾的是，音频素材的数量往往是有限的，而音频整合似乎成了一件无关紧要的任务。以至于在项目快要完成时，谁也不愿意费心去做。然而，为音频编程并不是一件容易的事情，假如没有在资源上给予相应支持，很可能会出现问题。对开发来说，Wwise 是一款非常重要的工具，可以带来以上三大好处。它不仅没有弊端，而且还可以有效缩短时间。从而提升音频管线的生产效率甚至整个工程的声音品质。

减轻编程的工作负荷

Wwise 具有单独的用户界面，允许声音设计师完全独立于游戏引擎来管理音频素材并构建游戏机制。利用它，声音设计师无需进行编程，便可迅速构建复杂的系统。如此一来，声音设计师就不用再花费大量时间来构建自定义脚本，也不必反复地与程序员进行沟通。同时，也好让程序员专注于核心玩法的设计。这样可以省掉程序员往常要做的很多工作，因为现在声音设计师自己就能全部搞定。 

1) 下面来看一段简单的 Wwise 整合代码：

 

PostEvent 将会是代码行中最常用到的函数。它可以在声音引擎中调用相应的 Event（事件），并通过该 Event 在 Wwise 中实现各种各样的操作。

2) 第二个常用的函数是 SetRTPCValue。

 

RTPC 是构建复杂动态音频处理系统的基础，它同样可以帮助我们节省大量时间。

在以下示例中，我会将代码中的实时 Car.Speed 值 (0 ~ 30) 关联到我在 Wwise 内创建的 SpeedBis RTPC。

 

如此一来，每次 Car.Speed 变化时，软件中的 RTPC 值就会实时更新。这样的话，在游戏中汽车速度加快时，风声就会逐渐增大。然后，我又调节了游戏当中的实时音量。整个过程只用了 5 ~ 10 分钟！

3) 我唯一需要跟程序员沟通的就是要为游戏机制使用哪些值，以及在哪里设置 PostEvent 函数来调用相应的 Event。这个过程只花了我几分钟时间，而且根本不用编写脚本。假如我想在品质上精益求精，还可请求程序员提供进一步支持。这大概需要 20 ~ 30 分钟时间，但这种情况并不多见。

我们来看一个简单的例子：汽车撞击周围地形（地图中的四种地形材质）。在发生碰撞时（On Collision Enter），声音引擎会调用相应的 Event。然后，检查上面的 Switch Container（切换开关容器），并根据标记选择要播放的相应素材。运行起来没有问题，只是现在是针对与脚本关联的 Game Object（游戏对象）发送 Event 的。这样的话，没法对汽车撞击地形的声音进行空间化处理。但是，我希望声音是 3D 的，所以必须在碰撞点触发 Event。

在程序员的帮助下，我构建了一种自定义方法：在碰撞时创建一个 Game Object，然后将标记信息发送给前述方法，同时以 objectHit 为碰撞点来播放声音。这样就可以实现 Wwise 中设置的 3D 定位了*。

为此确实多花了一些心思，但也就不到 20 分钟的时间。虽然要借助代码加以实现，但操作起来其实挺轻松的。因为只要完善一下现有功能就可以了，根本不需要另外创建。

4) 在脚本中添加一些基本函数，然后只要在 Wwise 中随便点两下就能完成设置，不像以前那样要花好几天的时间。比如，之前需要花费大量精力来设置与随机化相关的元素（关联浮点值或整数值）以及与音频素材的使用相关的元素。而且，即便完成了所有这些设置，自定义脚本有时也会出错，还可能会影响到性能。在理想状态下，我们希望程序员能够专注于游戏的核心功能，而不必耗费数小时、好几天甚至几个月来开发声音引擎（如 Wwise）已经能够实现的系统。

 

提高资源的利用效率

通过将 Wwise 连接到 Unity 会话或构建版本，我们可以深入地分析性能。相应地，也就可以进行实时混音和调节。Unity 虽然允许实时混音，但却不便在运行时更改影响音频的数值或其他参数。与之相比，Profiler（性能分析器）不仅能详细地显示各项数据，还方便在后期优化 CPU 和内存用量。利用 Wwise，我们无需编写代码便可构建精巧的游戏机制，同时完善声音系统并优化平台性能。 

1) 若想节省内存，必须压缩音频。为此，可针对每个目标平台选择最适合的设置。

我们可以为项目的各个发售平台设定不同的压缩设置。另外，还可选择在特定平台上弃用不需要的素材。

 

2) SoundBank（音频包）功能非常有用。利用 SoundBank，我们可以将所有工作内容分门别类，通过更加便捷的方式来部署音频。

这样的话，在特定时刻或在特定地图内就可以只加载与之相关的素材。最终实现复杂精细的控制，进而优化内存用量并提升平台性能。另外，SoundBank 还内置有便捷的语言本地化功能。这也是考虑到 Unity 和 Unreal 不支持在不同语言之间进行切换，也无法通过替换对白或其他语音来满足相应的本地化需要。 

3) Playback Limit（播放限值）功能对性能优化来说是一项非常关键的设置，它可以避免因脚本出错而产生各种故障或问题。

 

我们无需担心脚本会出于某种原因而触发 Event 上千次。在大部分情况下，直接通过限制文件/容器播放的实例数便可解决这一问题。这样就没必要麻烦程序员了，相应地也节约了项目资源。所以说，这一功能不可或缺，没有了它会很痛苦。

 

在达到声音实例限值时，我们可以将音频发送到 Virtual Voice（虚声部）。这样就可节省大量系统资源，因为引擎不会再处理这些音频，而只是计算其音量，直到需要再次使用相应文件。另外，在素材低于 Project Settings（工程设置）中设定的 Volume Thresholds（音量阈值）时，该机制同样适用。比方说，3D 对象距离听者太远，或者音频在后台反复运行（如汽车的 RPM 变化）。在这种情况下，声音是不可闻的，倘若仍像活跃声部一样处理，只会白白占用硬件资源。对此，完全可以将这些不可闻声音发送到 Virtual Voice。

我们可以充分利用 Wwise 的性能设置来完成所有这些调节和调整，来限制不必要的声音，从而节省内存和处理资源。

假如只使用游戏引擎而不结合运用声音引擎，我们就只能依赖于脚本。而且，我们都知道假如脚本执行不当，音频会极大影响性能。

 

提升工程的声音品质

虽然我们可以利用完备的声音库和录音，在数字音频工作站 (DAW) 内制作绝妙的音频素材，但是假如不能对这些素材适当地加以整合，一切就都是徒劳。利用功能强大的现成工具，可以轻松提升工程的品质。在实现精细控制的同时，性能自然会得到提升。

说实话，程序员并没有时间处理我们的所有请求，也没有精力满足全部的音频需求。作为一名声音设计师，假如总要求助程序员来完成各种小细节，那可能就不得不从大局出发而有所取舍。面对某些相对耗时的精妙细节，估计也就只能忍痛割爱了。就拿 Unity 来说，它不允许单独调整各个素材的音量。那么问题来了，如果自定义脚本涉及到一组共用同一音频源的音频文件，怎么办？所以，关键在于精细控制。只有协调好游戏中嵌入的各种元素，才有可能打造出完美的作品。假如不能有效地调节这些设置，混音效果必然会受到影响。同样的道理还适用于其他各种元素，比如音高、滤波器或其他在 Unity 中仅可应用于混音器或音频源的效果器。毕竟，我们都希望能够尽量减少音频源，确保可以对文件进行单独控制。

我在此文主要阐述了无论是对于声音设计师还是音频程序员，使用音频中间件都是有好处的。当然，音频中间件还可以为声音设计师带来很多其他便利。但是，有些效果只有通过 Wwise 才能实现，否则会耗费大量的时间和精力。

总而言之，工作的便捷肯定会带来作品品质的提升！

 

更多资源！ 

《How We Convince Developers to Let Us Use Wwise》- Richard Ludlow 演讲视频 (12:24) - 他解说了 Audiokinetic 如何根据项目预算设定合理的价格，从而满足各方需求。

《为何选择 Wwise》- Ciaran Walsh 于 2016 年发表的博文。

《Wwise Convinces Audio Programmers》- Audiokinetic 于 2016 年基于对多位程序员的采访发表的博文。

Wwise Pros & Cons with the Unreal Engine - Griffin Cohen 于 2017 年制作的图表。

* 本文所说 3D 定位针对 Wwise 2018.1 之前的 Wwise 版本。