简介

这篇博文将介绍 GME 语音聊天系统在 Wildlife Studios 开发的《Suspects: Mystery Mansion》游戏中的应用。文章由里奥•佩兰托尼（技术音频设计师）和菲利佩•洛佩斯（音频程序员）携手撰写。

我们负责使用 GME 来替代现有的语音系统 API。之所以如此，主要是为了提升音频品质并利用 Wwise 内部信号流和空间化结构及效果器链来提升对语音通道所发送内容的更多控制可能性。

《Suspects》是一款社交推理游戏，以原生语音聊天、大量独特游戏模式和定期内容更新为主要特色。

要想正确设置游戏中的语音聊天并不容易，因为这当中有很多影响其功能的情境规则。比如交叉实现 2D 和 3D 语音聊天，根据玩家状态收听不同的语音通道：死去的玩家在 3D 空间中听活着的玩家说话（带衰减），死去的玩家还会在 2D 空间中听彼此说话（不带衰减），与此同时确保活着的玩家只能听到彼此之间的谈话等等。若处理不好的话，会变得非常混乱！

下面我们将详细介绍如何借助适用于 Wwise 的 Tencent GME 插件来整合语音聊天系统。

GME 的多种使用方式

《Suspects》中有很多系统控制语音聊天的状态：

• 玩家操作（比如将自己和其他人静音和取消静音）
• 玩法操作（比如发起和结束紧急会议）
• 系统操作（比如信任与安全）

所有这些系统有可能会同时尝试改变语音聊天的状态。比方说，玩家想把自己的话筒调成静音，禁声系统要求其不能听到其他玩家说话，信任与安全系统限定所有人都不能说话。

为了实现这种分层系统，我们采用了意图设计。每个系统都要声明其语音聊天预期状态的意图。这些预期状态随后会被融合并应用于语音聊天控制（使用单个通道/房间）。

表决发言/紧急会议

在表决发言或紧急会议环节，玩家可以在 2D 空间中相互交谈。为此，我们会调用普通的接收和发送事件。在这种游戏状态下，玩家可将其他特定玩家（利用状态系统）或自己静音和取消静音。

我们使用了 AddAudioBlockList 和 RemoveAudioBlockList GME 事件来处理这些玩家操作，并在本地存储了被静音玩家列表以便在所有其他类型的语音聊天中应用相同的操作。

Ghost Chat 游戏模式

当某个玩家被假冒者放逐出局或杀死时，该玩家会被迫转入 Ghost Chat 游戏模式。这时其可以跟其他所有死去的玩家聊天。幽灵可以听到彼此以及其他活着的玩家（取决于游戏模式）说话，但若召开紧急会议，他们就只能听到活着的玩家在会议上的谈话。

对此，只在对局中将死去的玩家取消静音，他们就可以在 2D 空间中相互交谈。倘若发起紧急会议，将其再次静音即可。

Chit Chat 游戏模式

在 Chit Chat 游戏模式下，玩家要能跟附近的其他玩家交谈。为了实现这一功能，我们做了以下处理：

1. 使用距离半径值调用 SetRangeAudioRecvRange GME 事件方法。
2. 在 Wwise 中创建带有衰减的 3D 接收事件。
3. 针对表决发言环节的其他所有活着的玩家调用该事件。
4. 使用 SetUserID 方法中所用的同一 userID 调用 SetReceiveOpenIDWithGameObjectID GME 事件。

在执行所有这些处理后，便可开启 Chit Chat 对局。每次玩家移动，我们都会使用 SetSelfPosition 方法在 GME 中更新本地位置。

Chit Chat 模式下的紧急会议

Chit Chat 游戏模式下的紧急会议跟标准游戏模式的区别在于，我们必须在将玩家取消静音前在 3D 接收事件（Chit Chat 模式）和 2D 接收事件（标准模式）之间进行切换。在会议结束时会发生同样的情况，这时要使用空值调用 SetReceiveOpenIDWithGameObjectID GME 事件。

Chit Chat 模式下的幽灵聊天

这种情况是最不好处理的。幽灵可以在 2D 空间中听到彼此说话并相互交谈，并同时在 3D 空间中听到活着的玩家说话（带有衰减）。

为了实现这一功能，我们做了以下处理：

1. 调用 2D 接收事件。
2. 仅针对死去的玩家停止 3D 接收事件。
3. 仅针对死去的玩家使用空值调用 SetReceiveOpenIDWithGameObjectID GME 事件。

因为被静音玩家列表都是在本地进行处理的，所以活着的玩家永远不会听到幽灵聊天内容。

下图举例展示了《Suspects》中的语音聊天情形。其中，所有交互都在单个通道中执行并在客户端予以控制。

• 玩家 A 和 B 处于活着状态，其只能与彼此进行交谈。
• 玩家 C 和 D 处于死去状态，其可以与彼此进行交谈。同时，只能听玩家 A 和 B 说话，但是不能与之交谈。
• 玩家 E 和 F 处于活着状态，其在玩家 A 和 B 的衰减范围之外，只能与彼此进行交谈。

Wwise 整合

GME 实时语音插件在 Wwise中的 设置非常简单。在将该插件导入到 Wwise 会话中后，几乎马上就可使用创建的 Work Unit。考虑到情境语音聊天的不同需求，只需要稍微进行自定义设置即可。

自上而下的基本结构如下：

•  带有 Tencent GME Send 效果器（在效果器链末端实例化）的音频对象
• 带有 Tencent GME Receive 效果器的音频对象（此为从 Send 效果器接收信号的听者）
• 带有 Tencent GME Session 效果器的 Main System 音频设备（据此创建房间和用户 ID）

其实出厂设置的语音品质已经很好了，但是我们要处理有 10 个玩家的房间，而他们可能会同时在听对方说话，所以我们必须设法控制这些动态行为。在处理语音聊天时有个主要问题，就是其无法预测的行为。玩家可能会很安静，也可能会非常吵闹。不管是在安静的房间，还是在嘈杂的环境中。最终，我们决定使用一些 Wwise 插件来帮助管理这些无法预测的情形。

基于实际测试和相应方针，我们决定使用 Wwise Parametric EQ 处理某些不断冒出的刺耳频率，同时增强较高的频率来提升有些麦克风声音的清晰度。另外，为了处理多个玩家相互大声说话的情形，我们还在这个系统的信号路径的多个阶段使用了 Wwise Peak Limiter。最后，就在 GME Send 之前，我们使用了 Wwise Meter 来基于语音的音量控制角色形象周围的发光视效，以便玩家轻松辨别他们在听谁讲话。

在 Unity 中，我们会通过 GetRTPCValue 方法读取 Wwise Meter 值并发给服务器，以便将其复制到其他玩家的客户端来实现发光视效。

在 GME Send 之后，有两个带有 GME Receive 效果器的音频对象：一个用于不带衰减或扬声器声像摆位的 2D 聊天，一个用于带有衰减和定位的 3D 聊天（像普通发声体一样处理）。在最后，还会为 Main System 输出对象应用 GME Session 效果器。

现在有了 GME 系统，我们准备将来在语音聊天信号路径中实施更加灵活有创意的音频处理。比如，在 Ghost Chat 当中向 GME Send 添加一些延迟和混响（与死去的玩家对应的通道）。借助 GME，很多类似的功能都可轻松实现。

再来举个巧妙运用语音聊天的例子：基于与队友的距离将清晰的语音和无线电语音混合在一起。借助 GME，只需通过距离 RTPC 来控制效果器的干声/湿声参数便可轻松实现这一点。当达到 RTPC 阈值要在清晰的语音和无线电语音之间变换时，我们可以触发无线电噪音声来让音频效果更加富有沉浸感。

这当中会涉及到 Wwise 端的实现（参见上图）。

结语

GME 对语音聊天的快速迭代非常有用。只需在 Wwise 内添加各种必要的工具，便可轻松实现对语音品质的实时控制。

在此，我们要感谢 Wildlife 音频团队的鼎力相助（包括对语音聊天的测试和研讨）、《Suspects》工程和 QA 团队的支持以及《Suspects》社区的热心帮助。最后，希望大家能喜欢游戏的全新语音聊天功能。

试用 Wwise GME