本文将试着阐明我们在 Rovio 的同人如何使用 Wwise 及其他工具进行免费 (F2P) 手游音频开发，以及都采用了哪些策略来改进工作流程并提升工作效率。

简介 

有些人可能觉得手游音频开发跟 PC/主机游戏音频开发没什么两样，只不过工作量小一些而已，事实上手游音频有其独有的特点和挑战。作为一家大型手游开发商的声音设计师，我发现对免费 (F2P) 模式来说更是如此。在这种模式下，游戏的开发更像是一项长期的服务而非一次性产品。

即时服务游戏最典型的挑战在于要在其生命周期内不断地进行开发、维护和更新，而这一过程可能会持续数年。这需要有可靠的基础架构和可扩展的工具，同时要求相关人员具备一定的远见和准备。从这方面来说，手游和一些多人桌游有一些相似之处。

手游开发的另一特点（尤其是在规模较大的公司）是有很多项目同时进行。也就是说，开发周期都是重叠的。对于 PC/主机游戏开发，一般来说项目规模更大，开发周期也更长。而且，通常情况下同一时间只有一个项目在进行。在手游开发中刚好相反，会同时有好几个小项目，开发时间相对来说也比较短。

这里有张我们音频团队的写照，这些成员同时在参与多个项目。它们有不同的技术和设计需求，并且处于不同的制作阶段。此外，团队还承担着对即时产品进行维护并不断予以更新的工作。再加上对 F2P 游戏的持续迭代和测试，任何游戏都有可能因表现不佳或其他各种原因而被砍掉，并且新的原型还在不断地冒出来。不难想象，这样的团队需要机敏、高效的工作流程来应对所有这些挑战。在本文中，我将以最近的一些项目（比如最新的《Angry Birds》游戏）为例来试着从技术角度阐明 Rovio 团队是如何克服这些难题的（包括如何使用 Wwise 及其他工具）。

模板工程 

在处理多个项目时，最大的帮助来自于把我们所用的工具标准化。这样的话就可以将工作流程和相关改进运用到不同的项目中。学习可以是协同的，便于将之前使用相同系统学到的东西不断累积并加以实践。除此之外，要想确保对项目进行持续而高效的维护，还要使用可灵活扩展并满足未来需求的便捷工具。

对游戏音频设计师来说，最为重要的工具要数中间件或其他各种整合平台（原生或自定义游戏引擎工具等）。可以说，这些工具决定了我们工作的基本面；比如，如何准备所要整合的素材、如何构建播放系统和行为、当中都有哪些技术限制。通过在多个项目中使用相同的整合工具，我们可以灵活地运用与之前相近的做法。比如，动态混音、素材 (SoundBank) 打包、模板及预设。

我们使用 Wwise 作为首选中间件已经有一段时间了。所以，在存储库中保有模板 Wwise 工程，其可作为空白工程并用于构建新的工程。模板工程中有一些设置可以加快初始设置流程。比如，通用混音器层级结构、调试容器和 Event、模板 Actor-Mixer 和容器预设、常用 Game Sync、旁链 RTPC、Conversion Settings、ShareSet 等。有了为典型需求量身定制的模板工程，我们就可以在此基础来构建新的工程。这样比从头开始构建要来得更快一些。对于具体的工程，通常需要做一些自定义设置。不过，这也是件好事。因为这样不但可以省掉很多繁琐而重复的操作，还可促使我们重新审视所用的方法并加以完善。工程需要定期更新和维护来融入近期工程中所作的最新改进，这样才能在下一个工程中将这些改进应用到我们的整合当中。

Wwise 模板工程

过去，我试过把之前的 Wwise 工程做成模板来用到下一个工程中，但我发现这种做法不仅非常枯燥还很容易出错。而且，会阻碍你尝试新的方法和事物，并让你退回到熟悉的工作方式。 

AudioWrapper 封装器 

拥有标准中间件固然很好，但实际上有时候并不现实。每个项目都有自身的需求和特质，有时可能要使用一套不同的工具。比如，使用不同的中间件（或者不用中间件）、不同的引擎或者使用不同的工具维护原有工程…

我们有个用于 Unity 的自定义工具：AudioWrapper。它可以帮助应对此类情况。它最初由我的前同事菲利普•科尼克 (Filip Conic) 设计用作游戏引擎和音频中间件之间的封装类。通过使用 AudioWrapper，而不是仅仅依赖特定于中间件的集成，我们可以让音频代码不受中间件左右，确保所有工程当中的音频编程体验大致相同。有了这样的封装器，无论我们使用什么工具，面对的接口都是相近的。它让音频人员和可能对第三方 API 不熟悉的其他开发人员可以更加轻松地投入到多个项目中。

AudioWrapper 使用示例

AudioWrapper 还有一个很大的好处，就是可以在更高层面上将整合音频的方式标准化。每款游戏的设置方式都不一样，跟使用基于 GUI 的集成工具相比，通过代码整合声音可以让我们将自己的方式标准化，而不受制于游戏实体和逻辑是如何构建的。为了在所有项目中使用相近的整合工作流程，我们做出了这样的偏好选择。比如，如何触发、加载/卸载声音和音乐以及如何处理 Event。

使用封装器的附带好处是可以选择在开发过程中轻松切换中间件。这是一个很常见的情况。一般来说，会先用简单快速迭代的原生工具构建原型，稍后在项目投入力度加大时再切换到像 Wwise 这样的中间件以便利用便捷的高级功能。虽然主工具改变了，但语法还是一样的。而且，整套音频相关代码几乎不用怎么改就能用。 

针对 Event 的 Cooldown 系统 

封装器的使用会带来工具开发和维护上的一些额外开销，但对我们来说它的好处也是显而易见的。另外，它也使得在中间件功能之上加以构建来满足我们自身的需要变得更加容易。

作为一款 RPG 手游，《Darkfire Heroes》中包含大量的角色和动作，导致需要同时播放很多声部。鉴于手游在风格上更偏休闲一些，所以鼓励玩家保持开启声音已经存在一定困难。因此，让声音不那么杂乱并使其更加悦耳显得尤为重要。另外，我们希望能在给定时间随时向玩家揭示最为关键的信息，让玩家可以沉浸在游戏当中，而不必一直关注视觉信息。Wwise 中的声部限制和动态混音选项可以带来很大帮助，不过我想使用一些附加功能作为对 AudioWrapper 的扩展来封装 Wwise Event，以此获得额外的控制。为此，我构建了一个针对 Event 的 Cooldown 系统。藉此，我们可以在可调时间区间内限制后续 Event 的数量。在实现这一点之后，便可轻松添加更多的附加控件（如 Probability 和 Delay）。借助这些附加控件，我们可以对 Event（宏观）、Event Action 和声部（微观）电平进行更加精细的设置。这样的话，就可根据需要灵活调节来提高混音的清爽度。

《Darkfire Heroes》中的示例 AudioEvent 脚本化对象

在《Angry Birds: Journey》中，我的前同事米科•科莱梅宁 (Mikko Kolehmainen) 借用了《Darkfire Heroes》中的 Cooldown 系统，并将其改造成了 Audio Event Presets。在这一迭代中，我们没有封装中间件 Event，而是使用与之前类似的设置（Cooldown、Delay、Probability 等）来指定 Event 句柄（字符串）。如此一来，所有匹配的 Event 都会沿用这些设置。相比之下，对这一系统的维护以及批量更改的应用要容易得多。另外，这样还可带来一项额外的便利，就是所有这些数据都会存储为 XML 文件并预先加载，从而获得性能上的提升（在之前版本中，数据都是在运行时获取的）。从另一方面来说，它需要非常一致的命名方案；但话又说回来，谁会反对一个便捷、一致的命名规范呢？就像恰当合理的颜色规范一样，其本身就可以带来效率的提升！

《Angry Birds: Journey》中使用的 Audio Event Preset

动态混音 

Event 和声部限制只是提高混音清爽度的一个方面。另一方面是动态混音。藉此，可对持续输出且不可预测的声部加以筛选并为其设定优先级，来最大限度地确保整个声景清晰可辨、清爽悦耳。因此，出色的混音效果始于对混音器层级结构的合理设定。这样才能对游戏 Event 和结果声音动态地做出响应。

我们围绕优先级构建了整个混音器结构。与其仅用基于声音类型（环境声、音乐、玩法等）的总线，我们选择了充分利用基于声音优先级的结构。为了对优先级加以区分，我们设置了背景 (BG)、中景 (MG) 和前景 (FG) 这样的简单类别。不同的优先级分组会以 State、Auto-ducking 和 RTPC 的方式交互作用。

混音器结构示例

比如，在射击游戏中，武器可能具有高优先级，敌人动作具有中优先级，玩家动作具有低优先级。通过这种设定，可确保混音器结构和总线名称更通用，也更方便利用前面所说的混音器模板。不过，各个工程还是有自定义总线的，但主要总线之间的连接没有变。这样从一开始就可以轻松获得效果不错的混音。在大多数时候，只要稍微进行一点自定义设置即可。

《Darkfire Heroes》混音优先级示例

即时服务 

F2P 手游问世之后工作并没有结束。事实上，可以说才刚刚开始。手游的问世通常指的是全球上线，而这并不是终点，而是游戏即时服务的开始。在此之前，游戏已经试运营了一段时间。

这种多重发布模式对音频开发者来说意味着内容和功能是分阶段构建并在各个项目节点逐步推出的。试运营（即游戏仅在数量有限的地区发布）有点类似于付费游戏的 Alpha 测试。在全球发布之前，游戏会不断地更新和迭代，一步一步地走向 Beta 测试。在此期间，音频相关工作可能会逐渐增加。很多时候，会在接近发布日期的时候暴增。目标是在这一日期之前达到成熟水平，但实际上，有些功能到 Beta 阶段才会推出。在此之后，游戏发布会迎来下一阶段：即时服务。

在即时运营期间，游戏会通过定期（通常为每一个月或每两个月）更新加以完善、优化、修复和扩展。音频团队可以趁此机会完善和修复因为时间紧迫而未能达到预期水准的内容。不仅如此，每次更新还会增添新的功能和内容：新的机制、新的角色、新的章节、新的乐曲等。

借助这个难得的机会，可以重新审视声音效果并对不完美之处加以改进。即时服务游戏有一个很大的优势，就是可以通过这些初始更新更加轻松地对玩家反馈做出响应并进行必要的更改。可以想象，游戏发布后的前几次更新会让音频团队非常忙碌，后续更新的时候工作量才会慢慢减少。借助这些更新，还可深入了解游戏的核心主题并发掘更广阔的艺术创作空间。通过前几次更新，还可测试所用系统和结构的可扩展性。开发者可借此机会审视自身的工作流程并记下来以便日后改进。

撇开所有优势不谈，即时运营模式要求音频团队要做好每月交付内容的准备。不是一款游戏，而是很多！更不用说还有新的游戏要投入了。

像老板一样处理持续更新的关键在于要有完备的规划和高效的沟通。首先，要审慎地考虑后续会发布哪些内容，并为之相应地分配资源。其中的关键在于要把握好后续各个项目节点的时机。应当及时从制作人那里收集所有音频需求，同时有效传达音频方面的要求。

在为制作流程奠定坚实的基础之后，需要考虑使用哪些工具，以及如何制定相应的规范，确保能够在不引起问题或造成冲突的情况下更新游戏。具体到 Wwise 中，需要在兼顾可扩展性的情况下一如既往地构建层级结构、SoundBank 结构、模板和命名规范。为此，最好利用 Wwise Work Unit 来对内容分门别类。工作流程应当足够清晰和简单，这样即使对于刚加入进来的人，也能毫不费力地投入到项目中，并以惯常方式将新的素材与其余内容整合在一起。

在此之后，需要对各个阶段的内容进行测试。首先，会在游戏引擎内进行测试。在确定所有新的内容都可正确无误地运行（更重要的是，没有给游戏的其他部分造成破坏）后，便可在设备上测试构建内容。在设备上测试之前，我们会试着对构建内容本身进行测试，看看是否存在任何低级问题。为此，可将针对音频所做的工作放在版本控制工具的单独分支上。在确定构建内容没有任何错误后，音频团队和/或 QA 团队的成员便可在设备上进行测试。开发者可趁此机会从功能创意总监那里获得反馈（假设您已经在使用截取的游戏画面来整合内容之前这样做了，不过没有什么可以替代亲身的游戏体验）。

遵循这些步骤可以大大降低在即时运营更新中遇到问题的可能性。无论如何，为音频开发设定截止期限作为功能完成日期前的安全空档（至少一周）可以给您提供足够的时间来处理任何可能出现的问题（肯定会以某种方式发生）。 

最佳平衡点 

游戏音频突破了以往的很多技术限制，但手游在这个方面仍有一定进步空间。降低内存和 CPU 预算以适应配置较低的设备或紧凑包装尺寸带来的限制依然很重要。所以，在此有必要了解一下我们惯常使用的一些优化策略。

在老一代的手游中，我记得当中用过一些粗暴的做法。比如，将音乐降为单声道、将采样率降到一半（如 22.1 kHz）、使用音质最低的 Conversion Settings。甚至，还有一些发烧友用过更粗暴的做法…我们很幸运，现在不用再那么粗暴了。在 Rovio，我们设法不让自身的创意受制于任何技术限制。至少，我们会以开放宽容的态度进行创作，稍后再进行微调来适应现实的内存和处理限制。比如，对于《Darkfire Heroes》，我们在游戏里加入了超过 100 分钟的原创音乐，更不用说还有大量不同的角色和咒语了！ 

《Darkfire Heroes》原创音乐（国内观赏视频通道）

最常见的策略是采用相对保守的 Conversion Settings。这当中的诀窍在于要把握好在哪儿严在哪儿松。在决定要向声音应用哪种转码之前，我想先说几个简单的问题： 

• 声音的播放频率如何？ 
• 声音的播放时长如何？ 
• 声音对玩家体验有多重要？ 
• 声音的频谱和空间效果如何？ 

回答这些问题可以帮助我找到音质和性能之间的最佳平衡点。如果频繁播放声音，就会对 CPU 造成更大的负担，但加载速度会更快。另一方面，如果玩家会一直听到某个声音，那么音质就不能差。很少播放的声音通常容许较低的音质，因为它展示的只是一个转瞬即逝的细节。话说回来，如果声音对游戏体验具有重要意义，就要能够激励玩家，同时要有特色。比如，我可能想让其保持立体声和全采样率以便获取所有细节。

具体的应对措施会因游戏而异，因为优先级和目标总是不同的。不过，其同时也会为您指明正确的方向。基于对若干典型游戏的分析，我们确定了几种不同的预设。这些预设涵盖了我们 Wwise 模板中的常见转码情形。这样的话，从一开始就可快速获得较好的性能，稍后再根据需要调整采样率和压缩品质等参数。由于无法在 Wwise 中大幅降低比特率（但可降低采样率），所以我们更倾向于导出 48 kHz/16 比特（有时是 24 比特）的文件。

优化的另一方面在于控制同时播放的声部数和同时执行的进程数。现在，我们已经有了便捷的优先级和声部限制设置。同时，前面提到的针对 Event 的 Cooldown 系统也会带来很大的帮助。除此之外，我们还要充分利用属性沿用机制来设置 Actor-Mixer Hierarchy，并限制对 Actor-Mixer 或属性的冗余使用。同样的做法也适用于 Master-Mixer Hierarchy。比如，我们围绕 Time Stretch 插件构建了《Darkfire Heroes》中的整个 Actor-Mixer Hierarchy，以确保不会所有声部重复占用插件实例。这样的工程结构浏览起来有点枯燥，但确实对性能提升带来了很大帮助。 

《Darkfire Heroes》工程中的 Actor-Mixer Hierarchy

除此之外，我们还运用了其他一些小技巧。比如，修改常用的 RTPC 来仅应用线性曲线而非贝塞尔曲线。不过，我觉得最好的做法是从一开始就将素材和 Wwise 工程设计为可扩展的。这当中涉及到创建可以用在不同地方的共用素材，但也可能意味着首先要知道在哪里限制素材创建。比如，在《Darkfire Heroes》中，我们为每个敌人类型添加了自定义语音，但没有为敌人变体添加（火精灵和冰精灵使用了相同的语音）。不过，我们只使用了一组共用的攻击和命中声音。藉此可以赋予每种敌人不同的特色，同时将内存控制在我们的预算之内。另外还有一种比较好的做法，就是通过限制必须交付的内容数量来协调后续更新对内容的需求。

另外，做好 SoundBank 设置也可以带来很大帮助，尤其是在涉及到音乐和环境声这样的大文件时。我们通常会有一个核心数据包，其中包含一些 SoundBank（如 Meta 玩法和核心玩法元素、角色、UI 等）。在初始安装期间，就会下载这些 SoundBank。在此之后，会将带有新的音乐和环境声的新章节等内容作为可下载数据包包含在单独的 SoundBank 中。这样在很短时间内就可获得独特的音乐内容。至于游戏内音乐或环境声的变化，我们选择了以纵向分层和横向分段的方式来实现。我们的大部分音乐和环境声都包含多个分层和分段，并且其全部都做了随机化处理以降低重复的可能性。为了营造多样变化的游戏环境，我们对《Angry Birds: Journey》中的环境声做了非常灵活的设置。当中使用了很多随机化的参数，比如 Reverb Send、LFO、Envelope 和 Filter。环境声中的有些分层以 RTPC 的方式交互作用，以此来营造动态变化的环境。每一首游戏配乐都有四个前奏变化版本，让玩家每次踏入关卡都有不一样的感觉。这些乐曲从 A 点或 B 点开始，可能播放三个不同分层之一，来实现各种各样的音乐变化。 

《Angry Birds: Journey》– 从 Wwise 中导出的 Icy Caverns 章节的环境声（国内观赏视频通道）

《Angry Birds: Journey》– Icy Caverns 章节的音乐（国内观赏视频通道）

《Angry Birds: Journey》中的游戏配乐设置

结语 

手游有时被认为是 PC/主机游戏的缩小版或简化版。事实上，手游音频可以很深邃、很复杂，也可以很清新、很简单。确实，它有其自身的局限性和所要面临的挑战。但是，最大的限制一般来自游戏本身而非平台。为设计师提供广阔创作可能的游戏往往会产出富有想象力的声音，平淡无奇的项目则可能会让开发者在艺术创作上陷入沉闷的境地。只要有正确的理念和合适的工具，我相信所有其他限制都可以突破。