从项目需求的角度谈Wwise的接入

作者：nsmTech发布时间：2024-10-28

什么是Wwise？

Wwise是最好的游戏音频开发中间件

Wwise可提供一整套互动音频设计与开发工具，无论项目规模如何都能帮您轻松完成原型设计，并在此基础上将自己的音频创作构想变为现实。

Wwise的主要功能是将音频集成到游戏中并实现对音频的交互控制。它允许开发者将不同类型的音频资源（如音乐、音效、语音等）导入到项目中，并在游戏中根据不同的情境和玩家行为来实时播放和混合这些音频资源。开发者可以在游戏中创建各种Wwise音频事件，比如玩家触发某个事件时播放特定音效，或者在特定条件下触发背景音乐切换等等。这样的音频交互性使得游戏更加动态和丰富。

接入Wwise前的工作流

程序员直接对接的是音频设计师，专业知识不互通往往会造成研发进度缓慢、音频设计因“无法实现”遭受阉割。

程序员不懂什么是loop、one shot、低通、fade in、距离衰减、音频朝向这些音频专业术语。
音频设计师不懂什么是函数、参数、生命周期、CPU性能这些计算机专业术语，一方面不知如何和程序员解释自己的设计思路，另一方面在设计音频触发逻辑时往往忽略性能上的负荷。
最终的效果是程序导向的，游戏内音频的表现实际取决于程序员是否将音频资源正确触发。但实际上程序、甚至是QA都很难去判断。
音频设计师迭代优化的机会少之又少，或者成本（时间、人力）大。但音频的好坏通常又是在游戏的跑测过程中不断优化的。

接入Wwise后的工作流

音频设计师在Wwise工作站导入设计好的音乐、音效，在Wwise内设计触发逻辑并跑测优化至满意。将每个音频逻辑封装成一个个Wwise Event移交程序员。

程序员直接接触的的只有Wwise相关的接口和Event字段，无需再关注音频本身。
音频设计师在Wwise内可以无限次跑测*，最终提交的也是相对满意的效果。与程序对接只需提供Event名和接口名，无需再向程序解释自己的音频设计思路，简洁高效。

直观上谈Wwise带来的优势

一、音频相关工作解耦

音频、程序都只专注自己专业的领域。Wwise提供的现成的接口可以最大程度上保证不阉割音频效果，最终呈现来源设计师。

Wwise 的设计中始终有一条核心原则，那就是让声音设计师对声音行为的控制权达到最大，而对游戏代码的依赖降到最小。当开枪时，游戏只需要给 Wwise 发一个 Event，之后发生的一切，比如层叠、随机化、序列化声音组分或者影响别的声音全都掌握在声音设计师的手中。

声音设计师用 Soundcaster（声音选角器）可以离线测试这些声音行为，模拟游戏输入，这种模拟可以在集成到游戏中去之前或者比游戏有更强限制的对照条件下进行。所以，解除了音频和程序之间依赖关系也就保证了在编程之前就能够测试设计。结果就是我们可以在快速原型开发环境中清晰地验证声音行为是否正确，而避免了代价更大的程序迭代。

二、互动音乐系统

大多数游戏都需要某种形式的互动或者动态音乐，这是游戏引擎支持里面最薄弱的环节。Wwise 的解决方案足够灵活，可以支持任何手段，提供精确到采样点的同步和定制自由度非常高的过渡行为。系统由 State 来驱动，这意味着只需要在游戏或关卡开始时启动音乐系统，然后按需要去设置 States 就行了。

要自行实现一个互动音乐播放器，哪怕只是实现 Wwise 功能、时间精确度（对音乐同步至关重要）和易用度中的一小部分都很可能要花掉程序员好多个星期的时间。

三、快速执行操作并查看结果

Wwise 最强大的特性之一是其 Profiler（性能分析器）。Profiler 可以在游戏运行的时候把设计工具连接到游戏中去，并监视声音引擎里的一切活动。游戏中新来的 Events 及其引发的 Actions（动作）可以实时显示，这些动作包括比如声音的开播和停播，或者音量变化和定位信息。还可以显示错误信息、参数值和资源占用。这个工具用来调试和优化简直妙极了，可以节省巨大的时间，帮助我们快速弄清声音有没有在按计划运作，如果没有，原因又是什么。

所有一线游戏引擎自带的音频工具里没有能与其相提并论的，而且要自己实现 Profiler 能做的事情会很困难，代价会非常高。这里的问题不在于“要花多大代价去实现这个工具？”而是“不用这个工具会造成多大代价？”遇到一个 bug，用 Profiler 的话，声音设计师可以快速诊断并修正；否则会经常需要程序员帮忙和进行花费更大的 QA 测试，声音设计师修正起来也往往更花时间。