Hazelight Studios 开发的《It Takes Two》是一款专为合作模式设计的分屏平台动作冒险游戏，其因内容丰富多彩、画面新颖有趣而独树一帜。在为这样一款游戏构建声景时，最大的挑战源自分屏设计及其对音频的影响。

下面来听我们在 Hazelight Studios 的朋友说说其在为《It Takes Two》构建音频时都遇到了哪些挑战和机遇。在此，音频团队的首席声音设计师菲利普•埃里克森 (Philip Eriksson)、技术音频设计师乔基姆•埃尼格•萧伯格 (Joakim Enigk Sjöberg)、音频程序员格兰•克里斯蒂安森 (Göran Kristiansson) 和高级声音设计师安妮•索菲•蒙乔 (Anne-Sophie Mongeau) 会探讨其在分屏、混音、声音设计、性能和音乐方面采取了怎样的做法。本次访谈将揭示其为了向用户提供优质音频体验采取了哪些技术方案，以及这如何为同类游戏的音频制作树立了新的标准。

分屏

能否简要说说在《It Takes Two》中处理纵向分屏时采取了怎样的技术方案？

菲利普：我们对纵向画面分屏的处理方法是把混音也一分为二。将左侧、中置和右侧扬声器作为所有声音的基础，相对于后置扬声器来说始终优先选择前置扬声器。在左侧和中置扬声器之间对左边屏幕的声音实施声像摆位，同时将其中一小部分散布到右侧扬声器。事实上，玩家动作声、技能音效甚至角色语音都运用了这一技巧。另外，游戏中的环境声是四声道的，所以后置扬声器中也会播放。在游戏当中，两个角色在分处不同地点时会听到不同的环境声。对于右侧角色，我们会压低其左侧、前置和后置扬声器发出的环境声（对于左侧角色，采用相反做法）。这样可以确保呈现与屏幕空间相称的清爽体验。

图 1：对环境声实施声像摆位

在不从中间垂直分隔的情况下，对分屏的处理有没有什么不同？比如，在某个玩家一侧的空间变大、由纵向分屏变为横向分屏或者画面由分屏变为全屏的时候。

乔基姆：两个玩家在纵向分屏模式下占用同样的屏幕空间是目前最为普遍的情形，也是我们在技术上投入时间和精力最多的地方。除此之外，游戏当中还有一种常见的情形，就是两个玩家在全屏模式下共用同一画面。不过，在这些情形下，既定的空间布局框架并没有被完全打破。这一点对我们来说很重要。如此一来，即便视角不同，音频的行为规则也只是略有变动，玩家不注意的话可能都察觉不到。在全屏环节当中，我们的主要做法是相对于屏幕中点来追踪声源，并以此在横向平面上相应地对其实施声像摆位。这跟我们总体的屏幕空间管理理念是一致的，同时也极大地提高了此类玩法环节的清爽度，尽管这些环节本身往往画面缭乱、节奏紧张。

格兰：针对这种复杂情况，我们想到的其中一个技术方案是添加滤波插件。该滤波插件是个按声道配置的双二阶滤波器，其允许根据需要调节相应的音量推子和 Q 值。这样方便在玩家死亡和重生时对各个声道实施精细的控制。通过对一半混音进行低通滤波器扫频并针对每个玩家明确加以区分，我们最终获得了清爽的声音效果。由于玩法限制（比如长时间处于低 HP 值状态），我们无法对低通的那一半混音应用类似的效果。如果应用的时间过长，听觉效果会适得其反。所以，我们只把它用在了发生于转瞬之间的死亡/重生时刻。多亏 Wwise 中的现有代码库，插件的功能很容易就实现了。

那完全空间化 (3D) 的声音呢？两个玩家有时会处在相对于声源的不同位置。你们是如何设法避免在游戏世界中定位这些空间化声音时造成混淆的？ 

菲利普：这个处理起来要比 2D 声音稍微棘手一点。在为游戏制作声音的过程中，我们很早就意识到了这个问题，不过直到很晚才想到解决办法。有个最简单的例子：某个玩家可能处在离声源很近的地方，但其摄像机是偏的，而另一玩家离声源相对较远一点，但是正对着它。在这种情况下，混音叠加之后声音会同时出现在前置和后置扬声器中，导致感知的声音范围很宽、音量很大（跟预期相比）。就我个人感觉，这会产生违和感。这样就把游戏交了肯定是不行的。我们有一条坚定不移的原则，就是在实施声像摆位和混音时优先考虑有声源在视野之内发声的玩家。但这个问题把规则打破了，所以我们必须得做点什么。

乔基姆：我们在此看到的问题基于项目本身特定的听者设置。这里有两大痛点。第一个是空间音效如何定位。对于最靠近空间声源的玩家，通常产生的混音输出最响亮，其视角对扬声器部署的影响也最大。其视野往往跟设计师其时要关注的东西不符，然而我们并没有现成的工具来对此加以调控。

第二个是 Wwise 本身如何针对听者组合声道。在来自空间音效的输出被两个玩家听到时，信号量会翻倍；跟只有一个玩家听到同样的声音相比，其输出音量增大了。这会对最终结果产生难以预测的影响，因为各个声道的信号量完全取决于两个玩家具体在声源的什么位置。

在开始将声音整合到游戏中时，我们很快发现了空间化发声体的振幅问题。为此，我们先是创建了一个非常简单的 RTPC，并将之与上层 Actor-Mixer 的 Make-Up Gain 绑定。对于每一播放空间化声音的发声体，都会追踪听者的相对距离。当两者都在范围之内时，会持续更新此 RTPC 以根据两者的距离降低音量 – 所有这些都是为了抵消声道加倍带来的强度增加。当然，这种修复非常蹩脚。而且，因为没法准确预测两个听者加在一起的信号量，整体实现起来并没有获得理想的振幅平坦化结果。

由于这两个问题的存在，我们根本无法控制游戏的空间混音。为此，我们决定深入探究 Wwise 的底层逻辑，以便在如何处理《It Takes Two》中的空间化声源方面制定自己的规则。

图 2 & 3：一个空间声源，两条听者通路

格兰：在 Wwise 系统中建立自己的规则之前，我们需要先了解 Wwise 本身的规则。为此，我们详细考查了目前都有什么、哪些需要调整以及在哪里做调整。

就像前面说的，我们开始得很晚。所以，要斟酌如何在保证项目进度的情况下获得想要的结果。就设计需求而言，我们的目标是消除信号重复的问题，并依据指向性聚焦来对信号加以限制，以此构建自己的 Spatial Panning 系统。

为此，需要知晓衰减范围内的所有听者及其相对于各个发声体的朝向。最终，我们选择了主要根据距离来对信号变化做平滑过渡。同时，间接借助玩法来控制指向性信号平滑过渡的速度，因为在大多数情况下旋转变化都相当可控和平滑。为了减轻对性能的影响并按照所需格式获取数据，我们不得不在 Wwise 系统中做一系列的调整以求获得想要的结果和性能。

有没有发现这一 Spatial Panning 解决方案固然很有帮助但也造成了其他问题？有的话，都是什么问题？采用了什么方法加以避免？

菲利普：我们对这一问题的修复并非完美无暇，玩家仔细听的话肯定能听出点什么来。但是，它解决的问题绝对比造成的问题多。我们的解决方案涉及到移动的声音（比如由后置扬声器转到前置扬声器），所以需要通过创建线性插值来实现平滑的过渡。如果玩家控制角色快速做出剧烈动作，即便基于各种潜在情形做了精细调整，线性插值感觉起来还是可能有点迟缓。但是，游戏中并不存在玩家独自聆听某一声源的情形，所以很难对整个混音当中的个别问题进行甄别。

乔基姆：Spatial Panning 功能是专门为了解决我们在《It Takes Two》中遇到的问题而构建的。在这个项目的开发过程中，为了获得最终想要的结果而采取的各种方案（包括 Spatial Panning）并非宽泛地面向所有以“动作”为主要表现形式的分屏游戏；相反，它们是为《It Takes Two》量身打造的。比如，它的玩法非常线性；玩家总是向前移动，当中触发的所有空间音效都是据此设计的。虽然我们的解决方案在这样的游戏环境下效果很好，但并不意味着其对开放世界或玩家视角不对称的游戏也有效。当然，我们将来可以在 Spatial Panning 理念的基础上不断进行拓展。但是，在开发新的游戏时肯定要对其具体需求做重新的思考。

格兰：由于游戏的发行正好赶上新主机的发布，鉴于新主机本身的问题和特点，我们不得不频繁更新 Wwise 版本。这也意味着我们要花大量时间来确保各项功能（如 Spatial Panning）运行良好。在使用第三方软件时，这是常有的事情，没什么好奇怪的。不过在对现有软件做出修改时最好记住一件事情，那就是构建配套工具（或使用现有工具）来尽量帮助实现这一过程，同时在代码库中清晰标记所作的改动。这样可以降低在不同版本之间迁移时的成本。

混音

《It Takes Two》的混音效果听起来很不错。虽然存在分屏的问题，但感觉一直都很清爽。在对游戏进行混音时采用了怎样的方法？当时有什么设想？如何投入实际应用的？

菲利普：我们想打造富有变化、充满乐趣的混音，确保始终聚焦于引人注目的新鲜事物上。这款游戏非常线性，相比开放世界游戏，实现起来容易很多。当玩家在房间之间穿梭或沿着主路移动时，只要不断聚焦于有趣的声音和事件上即可。这一点大部分都是通过混音决策实现的，为此要仔细甄选哪个玩家应当听到什么。在音频团队观摩会议中，从制作音效到完成终混，我们一直在想这个问题。最终我们决定由两个人合作完成混音，以此确保游戏能够像设计的那样运作。这也使得整个混音过程充满了乐趣，而且有人协助和探讨确实很有帮助。

安妮•索菲：分屏对我们的有些混音决策产生了很大的影响。比如，我们没有试图总是把两边屏幕分开并将之看作一种阻碍，而是选择理性地看待分屏设计并巧妙地借助声音来叙事，以此突显两边屏幕中当前的关键元素并通过混音来强化。通过每次聚焦于一个重要元素，我们可以告诉玩家要关注什么。这一点在场面宏大、节奏紧张的战斗场景当中尤为重要。有时这意味着要在呈现内容上把控得非常严苛，但也正因如此才确保了混音的清爽度和一致性。

有没有考虑过基于播放配置呈现不同的混音？比如，借助耳机为两个本地玩家提供不同的混音，或者在两个联机玩家的终端分别加以处理？

菲利普：在音频制作之初，我就想过这个问题，也萌生过一些想法。比如，压低自身角色的动作声和对方角色的说话声。或者，将另一玩家在游戏世界中听到的环境声静音。但是后来对玩家体验做了一下设想，发觉这些想法并没有什么实际用处。因为不管对于哪种游戏模式，在画面表现方面都是一样的。所以，合理的做法是采用同样的声音处理方式。否则的话，不同的混音还要单独维护，反而会增加我们的工作量。与此同时，我们也力争在两个玩家处于全屏模式、身处相同声景时提供恰如其分的音频体验。尤其对于像《It Takes Two》这样的游戏，我觉得更应该借助声音设计来让玩家彼此之间感同身受、情意相通。

HDR

《It Takes Two》有没有使用 Wwise HDR？怎么设法做到既满足自身需求又贴合分屏设计的？

菲利普：我们确实使用了 Wwise HDR。这个很容易做出选择。我们要利用 HDR 清理混音，剔除那些听不到的声音，以此来对游戏进行优化。之前在 EA DICE 的时候，不少游戏开发当中都用过 HDR。稍加测试一下，很快对 Wwise HDR 就熟了。下面是我总结的一些技巧和窍门：

• 对声音的响度进行归一化处理；
• 规定要针对不同类别的声音使用怎样的 Voice Volume 值，或者明确哪些声音在混音当中最为关键（不一定非得响度最大，也可以是有趣的声音）；
• 尽量让 Voice Volume 值保持不变（距离衰减除外）。比如，不要对 Voice Volume 值应用随机 LFO RTPC。否则，自身声音会将其他声音压低（或者被其他声音压低），每次的调节效果都不一样，最终可能会显得杂乱无章。
• 针对所有可变音量和整体混音使用 Make-Up Gain；
• 倘若同一音效对应有多个分层，要注意各个声部可能具有不同的 Voice Volume 值，这样的话那些要一起播放的分层也会被压低。明智的做法是为要一起播放的分层设置相同的 Voice Volume 值，并使用 Make-Up Gain 对这些分层之间的声像摆位统一进行处理；
• 注意，如果将 Voice Volume 设为低于 HDR 窗口范围下限的数值，并且在 Virtual Voice Behavior 中选择了相应设置，自身的声音很可能会被剔除。可以有意为之，但要心里有数。

另外我们还发现，有两个听者也意味着同一时间会有两个 HDR 实例。也就是说，假如某一听者处在 Voice Volume 较高的声源旁边，而另一听者处在衰减范围之外，那么叠加之后的 HDR 闪避幅度将弱于两个听者都靠近声源的情形。这种行为未必是我们想要的。

图 4：利用 Voice Monitor 直观地呈现 HDR 数据

混响效果器

《It Takes Two》的混响和整体环境听起来非常真切。使用了哪种混响效果器？把这些环境打造得如此逼真，还探究过哪些解决方案？

菲利普：《It Takes Two》音频监制的核心宗旨在于为玩家提供沉浸体验，让游戏世界对声音做出响应以激起玩家的共鸣。我们希望能够构建一个美轮美奂、富有新意的游戏环境，比如吸尘臂、玻璃罐以及万花筒关卡中的怪异混响效果。为此，我们尝试使用了 Wwise RoomVerb 插件，但其并不能完全满足我们的需求。最终，我们决定只使用卷积混响效果器来根据需要灵活地加以调节。我们使用鞭子和烟花对不同环境做了大量冲激响应录音，并为水下及其他奇幻场景精细设计了很多冲激信号样本。

除了这些卷积混响效果器，我们还构建了 Environment Type 系统，以便能够播放各种专门设计的反射尾音。我们主要将这些尾音用在了爆炸声和武器声上。其他一些借助较长尾音传达空间和响度特性的声音对此也有应用。事实上，我们专门制作了两个不同版本的脚步声尾音：一个用于小房间，一个用于大房间。

为了将游戏世界打造得更加逼真，我们构建了运行时延迟系统。该系统借助射线投射推断从角色到反射表面的距离及表面类型。这样较为静态的混响和人为设计的反射会更加自然，确保游戏世界能够对非常细小的变化快速做出反应。

图 5：针对特定关卡调节 Convolution Reverb 的 Impulse Response 设置

乔基姆：在设计相应系统来模拟声音播放起来的环境效果时，要明确频谱是预先设定好的还是在运行时动态调节。基于现实资源和理论构想，设法在两者之间找到合适的平衡点，努力做到兼顾技术需求和创作愿景。就《It Takes Two》中的环境系统而言，我们希望能够通过卷积处理来实现混响效果。虽然我们最终要在运行时动态地将信号馈送到这些总线中，但效果器自身特性却是为渲染特定类型的环境预先设计的。在玩家在游戏当中移动时会监控其位置，并据此设法将信号输出到对应混响总线，不过混响本身的声音效果是相当固定的。

另一方面，有了坚实可靠的混响基底，我们就可以大胆地使用可变延迟线来表现早期反射物理现象。这些可变延迟线由从游戏中收集的各种数据（比如到墙壁的距离、听者周围的材质以及与周围物体的关系）驱动的实时计算控制。

任何一种系统，无论是预先设定好的还是在游戏运行时动态调节，都有其自身的优点和缺点。不过，只要结合加以运用就可打造出逼真的数字世界。

格兰：遗憾的是，Wwise 中的延迟插件缺少可变延迟时间功能。换句话说，就是不支持在运行时通过 RTPC 来调节延迟时间。然而，这对我们的早期反射系统来说是必不可少的。

最初，在设计原型的时候，我们使用了 Pure Data。除此之外，还基于 Pure Data 补丁（使用现已停止维护的 Heavy 编译器生成）构建了 Wwise 插件，以便在引擎中做各种各样的尝试。注意，并不是所有的平台都受Heavy支持，而且可能无法马上拿来使用。

刚开始，我们尝试了使用磁带延迟，但在更新延迟时间时会发生音高变化。后来，又尝试了使用延迟线及可变延迟时间，但在更新延迟时间时会产生杂音（如噼啪噪声）。不过，结果足以说明可能会得到怎样的效果。在此基础之上，我们可以继续构建自己的 Wwise 插件。

最终，我们使用了带有双三次插值的分数延迟线来消除更改延迟时间时可能产生的噪音。

图 6：Hazelight 自己构建的 Wwise 插件 Haze Delay，利用分数延迟线消除更改延迟时间时可能产生的噪音

分屏意味着可能要在同一时间处理好多卷积混响效果器实例。对延迟来说，同样如此。前面所说的系统有没有造成什么性能问题？如果有，是怎么解决的？

菲利普：两个角色很有可能处在不同的环境区域，甚至处在不同环境区域之间的淡变区域。也就是说，只有角色声音才会被同时混音到四个卷积混响效果器中。另外，我们还将其他环境区域中的声音混音到了该区域的混响效果器。所以，同一时间可能会有大量的混响效果器实例。借助运行时延迟系统，实现起来会简单一些。在这种情况下，仅以角色为中心对声音进行延迟处理，同一时间最多只会有四个延迟实例（每个角色两个）。

乔基姆：在《It Takes Two》中，混响效果器总线跟游戏世界中的环境区域关联，只有在玩家进入其所代表的区域时才会被激活。同样地，在该区域没有任何玩家时，关联的混响发送会被剔除，总线会逐渐变回停用状态。在游戏当中，玩家会不断触发周边的混响效果器实例。这些实例会在彼此之间交叉淡变，让玩家自然而然地进入下一环境。在没有任何来自当前玩家的输入信号时，其会转入休眠状态。前面也说了，两个玩家可能处在完全不同的位置。为了提供相应的支持，我们对这一系统进行了精心的设计。即便如此，还是会有七八条卷积混响效果器总线同时处于激活状态的情况。这是跟玩家所处的位置和游戏世界内的其他声音相关的。在开发过程中，Audiokinetic 自己也对卷积混响效果器进行了性能优化 – 非常感谢！

格兰：为了减轻处理负荷，我们一直在琢磨如何限制所要处理的对象数量。最后想到了一个好办法，就是剔除不活跃的对象。比如，那些不播放任何声音或超出范围的对象。

除此之外，我们还确保了只在必要时更新数据。比如，对于延迟系统，我们使用了异步射线投射。并且，只有在足够的数据发生变化时才会更新延迟插件。藉此，尽可能减少了对可变延迟线的调节，但代价是所有调节都不在当前帧上。

性能

除混响效果器外，分屏还意味着基本上任何时候都会并行运行同一游戏的两个实例。这有没有给性能带来什么大的问题？主要都有哪些担忧？是如何解决的？

菲利普：在整个音频制作过程中，我们一直在想这个问题。这是理所当然的。想把游戏音频打造得引人入胜并不容易，到最后可能要舍弃很多费心创作的东西。为此，我们几乎从一开始就在监控数据，确保其始终处在合理的体量之内。在声音设计当中尽量只在必要时使用相应分层，并借助混音决策及 HDR 剔除那些不必要的声音。这并没有给我们的创作带来什么阻碍。不过，有时为了兼顾声音和优化需求不得不调整设计手法。除此之外，我们还结合使用了 Wwise 内置的各种优化系统（如 HDR、Playback Limit、Virtual Voice Behavior 和 Playback Priority）。

乔基姆：对于任何一款游戏，同时播放大量声音几乎都会严重消耗 CPU 资源，像《It Takes Two》这样的分屏游戏当然也不例外。主要的办法是对声部和总线做出限制。不过，HDR 在这方面的效用也相当出色。藉此，不仅可以获得清爽、动态的混音效果，还可减少对游戏中的次要声音的处理，在达到既定音量阈值以下时将其剔除。

《It Takes Two》支持五种不同的平台，其需求、要求、弱点和优点各不相同。我们的做法是不断甄别存在严重冲突的地方，确保游戏在所有主机环境下都能够顺畅运行。这样的话，便不必在 Wwise 中为不同的平台单独设置层级结构。为了找到一个对所有设备来说都能接受的平衡点，我们对声音设计方案反复做了很多的调整和改进。比如，对从磁盘进行流播放的声音样本进行归类。在开发当中，我们发现这会对性能产生直接的影响。除此之外，我们还综合考量了其他一些因素。比如，处理器花在音频帧上的时间、RAM 中未压缩的 PCM 数据量以及硬盘驱动的流媒体数量。

即便 Wwise 只有 Profiler 功能，我还是会用。

格兰：澄清一下，并不会同时运行两个游戏实例，只是两个玩家的视角有所不同。就听觉体验而言，总是有两个听者。也就是说只有一个音频源，但信号进行了单独的混音。

正如乔基姆前面提到的，我们主要关注的是同时播放的声音数量及各自的复杂程度。比如，有些需要每帧更新多个 RTPC、混响效果器和位置。为了明确区分各个对象的不同要求以提升整体开发效率，我们做了大量的设置并创建了很多简单易用的快捷方式。比方说 Fire-Forget 声音，播一遍马上就会被停用，直至需要播放另一声音。为了确定什么时候可以停用大部分声音对象，我们充分利用了衰减半径并做了相应的补充，来兼顾两个听者的移动速度以保障听觉体验。

声音设计

《It Takes Two》的玩法多种多样。这意味着要为音频创建大量的内容。怎么设法做到这一点的？有没有跟外包公司合作？

菲利普：确实，我们跟 Red Pipe Studios 就有合作。所有过场动画的声音和混音都是他们做的。在音乐方面，我们跟克里斯托弗•恩格 (Kristofer Eng) 进行了合作。他跟我们的专职作曲家古斯塔夫•格雷夫伯格 (Gustaf Grefberg) 组成了二人作曲搭档。游戏内几乎所有的旁白录音和初步剪辑都是 SIDE 做的。在为过场动画设计拟音的时候，Red Pipe 还跟 Foley Walkers 进行了合作。我跟 Ton & Vision 的声音设计师帕特里克•斯特伦达尔 (Patrik Strömdahl) 做了大量的拟音录制工作。

说实话，在《It Takes Two》的音频制作过程中，我们的时间一直都很紧张。所以，才流传着“第一遍就是最后一遍”这样的笑话。不过，实际情况跟这也差不了多少。大部分情况下都是一步到位，因为可能根本没时间回过头来再做改进。我倒觉得这样挺好。说得极端一点，我宁可把整个游戏的声音做得差强人意，也不愿只把第一关的声音做得无可挑剔。

虽然无奈之下不得不这么做，但在质量方面我们从不含糊。照制作经理的话说，“把标准设得高高的，认准了就贯彻到底，无论如何都不妥协”。我们的目标就是打造独树一帜的分屏游戏，即便项目工期很紧也不会做出丝毫的妥协。

我们最后确实空出了一点时间，也回过头增添了一些声音，还做了一些改进。一直到游戏基本做好交给客户，都在想方设法将音频打造得尽善尽美。

安妮•索菲：多亏了菲利普在整个项目期间的周密规划，我们才得以为游戏制作出这么优质的内容。对我们的声音设计、制作与整合、技术系统开发与迭代和过场动画音频外包来说同样如此。我们基本上给每个关卡和子关卡都设定了期限，在可能的情况下会多留一些时间做改进和混音。一旦某一阶段的时间用完了，马上要转入下一阶段的制作。面临如此巨大的时间压力，我们只有设法在第一次迭代的时候就把所有东西都做得达到发行质量（包括声音设计和混音）。自始至终，我们每个人都抱着认真负责的态度，无论新旧素材在质量上都绝不含糊。同时，充分发掘各自的创作潜力，确保把所有景物和角色都打造得鲜活如生。总的来说，这么多的内容确实是个挑战，不过项目当中也充满了乐趣。 

音乐

Music 关卡是游戏的最后一关，声音效果非常出色。在歌唱技能上是怎么处理的？有没有以对拍的方式让音乐推动剧情的发展？

乔基姆：在 Music 关卡中，有很多的玩法元素。从某种形式上来说，都是受背景音乐控制的。这当中最重要的要数 May 的 Singing Ability。她要用该技能解决谜题，在关卡中一步一步向前。每次玩家一激活该技能，May 就会随着当前播放的音乐歌唱，跟着曲速和曲调手舞足蹈。为了实现这一点，我们选择了让歌手以 MIDI 音轨为模板来演唱乐曲。然后，又将 MIDI 数据解析为标记点并被植入到了源文件中，以便稍后由游戏引擎读取并告知于系统。

说到让玩法与音频线程上发生的事件保持同步，我们必须考虑这样一个事实：《It Takes Two》不仅有本地模式（两个玩家共用同一设备），还有联机模式（两个玩家通过网络互动）。对于后一种情况，会有两个单独的游戏实例存在，同时也会有两个独立的 Wwise 实例运行。两个游戏实例之间会一直在玩法状态上进行通信，但两个 Wwise 实例之间并没有交流，其只是在本地播放声音并对之做出反应。音频线程的性质意味着其会以固定的速度运行，但由于主线程的每一帧都要花很多毫秒来计算，两端的声音有可能会在不同的时间开始和结束。对大多玩法来说，这一点无关紧要。两个玩家心意相通，一般不会被此困扰。但是，如果一方等待音频线程传递事件，双方又要在游戏中同时触发事件，那么时机就成为了一个关键因素。

对于 Music 关卡，我们面临着这样的现实，而且别的方面也要顾及。即便如此，我们还是使用了大量音乐回调来自由触发那些对时机要求不高的事件（比如背景效果和其他花絮画面）。这些事件随时都可以发生，但要确保画面始终与音乐保持同步。

双方都能感受到播放音乐时对游戏世界产生的影响，所以说并不存在对方的操作让自己毫无防备的情况。

Wwise

能否简单说说将 Wwise 作为音频引擎的优劣之处？对此采取了怎样的补救措施？

菲利普：《It Takes Two》是我用 Wwise 制作的第一部游戏。我觉得，Wwise 最好的一点就是稳定可靠。这一点非常好。运行起来一直都很流畅。当然，我们在使用 Wwise 时也遇到了一些技术问题。但是只要稍加变通都可以解决，并没有到工作无法推进的程度。另外，除了我，团队里还有很多 Wwise 专家，包括安妮•索菲和乔基姆。他们都可以给音频团队的其他成员提供指导。而且，我发现 Wwise 非常容易上手。只要肯花心思，很快就能掌握。

全球各地有很多音频团队都在使用 Wwise，这从很多方面来说都是件好事。不过也正是因为这样，Wwise 的功能并不特别针对某一团队或者某款游戏。所以，在大部分情况下，我们要自己寻找分屏的处理方案。比方说，如何将 Balance-Fade (2D) 声音输出到中置声道。我们希望在游戏中大量使用中置声道来将声音一分为二，同时有选择性地在两者之间进行分配来保证立体声效果。但是，Wwise 并不支持使用 Balance-Fade 和 Center Percentage 调节发送信号。为此，我们只好改为通过创建大量辅助总线来将信号发送到中置声道。

图 7：变通之法 – 创建辅助总线来将信号发送到中置声道

乔基姆：Wwise 有自己独特的行为机制，并不是说你想让它怎样就怎样。作为一个框架，它显然包含了很多现代声音引擎应当具备的基本功能。对于认真考虑使用 Wwise 为游戏打造绝妙音频的人，我想说，它并不是一个能够满足所有声音设计需求的终极解决方案。

这样的第三方工具是不存在的。每款游戏的玩法都不一样，不可能有普适的解决方案。

你可以把它当做一个很好的起点。它有一套完备的功能，运行起来非常稳定。你可以在其基础之上发挥自己的创意。如果你只对它本身的功能感兴趣，迟早会感到失望。如果你想利用它创造属于自己的东西，会有无限的可能。

为了扩展 Wwise 的功能以更好地满足自身需要，我们调整了在有多个听者时对空间化信号的处理方式。刚开始的设置效果并不理想，反而减弱了整体上的沉浸感。我们早期的很多尝试和努力都没有成功，Wwise 并不能提供满足所有需求的方案。

好在 Wwise 的架构是开放式的，允许用户根据需要自行设置。于是，我们就对底层系统做了大幅调整，以此来满足自己的特定需求。最终，我们构建了自己的 Spatial Panning 系统。

格兰：这是我作为音频程序员参与的第一个项目，而且到制作后期才加入到团队中。我的一项重要任务是针对 Wwise 实施改进并构建自动化工具。在这当中，WAAPI 为我提供了很大的帮助。无论采用哪种编程语言，都能利用 Wwise 的设计功能。然而，WAAPI 的功能并不完善，但大部分情况下都很好用，而且Audiokinetic 一直都在对其进行更新和改进。

在制作开始的时候，Unreal 中还没有 Event-Based Packaging 这样的概念。不过，我们很早对此就有自己的想法。虽然我们对基于事件的音频包生成有自己的方案，但在生成 .bnk 和 .wem 文件时，最终还是采用了 Wwise 提供的生成方式。这种做法既可靠又高效。考虑到在迭代当中浪费的时间，顺利地完成工作才是最重要的。 

就分屏游戏而言，各位在 Wwise 的使用方面有何建议？

菲利普：制定声像摆位和混音规则并一以贯之。不过，在为分屏游戏制作音频时，可能需要做出一定的妥协。无非就是优先处理所需的声音并制定相应规则来确保大部分声音的效果。做出这样的选择可能会很困难，但为了给玩家提供愉悦的体验，也只能如此。

乔基姆：尽早看看游戏的视觉框架，站在声音设计师的角度，确定其中哪些元素重要。设法明确基准点，并据此确保空间上的一致性，以便在帧内恰当地定位声音。无论是在 Wwise 内还是在原始素材创建上，越早确立相应的规则和体系，内容增多后管理起来越轻松。还有，就是尽情尝试自己的想法。分屏游戏的音频构建还有很多未经探索的领域，各位完全可以按照自己的方式借助声音来叙事。

格兰：作为音频程序员，我真不知道要是没有 Wwise 源代码该怎么办。所以说，一定要了解代码库，不要害怕把事情搞砸。

安妮•索菲：我赞同菲利普关于制定声像摆位和混音规则并一以贯之的说法。最终，声音的空间化方式将决定分屏游戏的听觉效果。所以，最好尽早明确这一点并形成规则，然后在后续工作当中落实和贯彻，这样可以省掉很多不必要的麻烦。以《It Takes Two》为例，有条混音规则就挺实用，即不追求将声源完全空间化，而是着重基于屏幕空间来构建声景。这样的话，便可根据与玩家的关系及摄像机的角度来播放声音。藉此，不仅可以提高混音的清爽度，还能最大限度地减少由分屏带来的混乱。“基于屏幕空间”的意思是有意将很多非空间化 (2D) 声音放到 Left-Center-Right 扬声器中播放，就像在电影之类的线性媒体中做的那样，以此确保尽可能精准地与画面保持一致。当然这只适用于部分特定的声音，比如角色本身产生的声音（拟音、角色驾驶车辆的声音、玩家技能音效），或者始终处在画面帧之内的声源发出的声音（比如较短的一次性声音）。总的来说，对于线性分屏游戏，我建议至少要探索一下更具确定性的声音设计和混音方法而不是不加区分地进行空间化处理。

说到底，正是由于创作和技术人员之间的精诚协作，Hazelight 音频团队才得以成功解决自己面临的各种难题。毫无疑问，声音设计师、作曲家、技术音频设计师、音频程序员都贡献了自己的一份力量。他们相互学习、彼此信任、密切交流、群策群力，最终将质量标准提高到了前所未有的高度。在《It Takes Two》音频体验大获成功的背后，是对目标的清晰认识、对规则的认真贯彻、对可靠工具的灵活运用以及对音频设计的执着追求。