浅析游戏中的音频GameObject管理

1、浅析游戏中的音频GameObject管理GameObject是使用Wwise进行音频设计的基础理念，从Wwise基础功能的使用（尤其是Profiling），到使用WwiseSDK开发都会涉及这一概念。笔者在日常工作中遇到过不少因为音频GameObject管理不善而引发的问题。故而尝试对音频GameObject的注册与管理方法进行一定的梳理。首先我们来介绍一下关于本问题的相关背景和一些基础概念。1、什么是GameObject？首先我们来统一一下概念。为了避免大家和广义上游戏引擎中的GameObject以及Object-Based Mixing等概念相混淆，此处的定义以Wwise引擎中关于Game

2、Object的定义为准：同时为了与Wwise的界面及文档统一，后文中也统一使用（Wwise中的）GameObject这一名称。2、为什么要进行音频对象管理？由上文可知，GameObject是Wwise中的核心概念Wwise对音频的管理都是基于管理GameObject来实现的。可以说，在使用Wwise的情况下，游戏中任何声音的播放都离不开GameObject（无论声音是2D/3D）。若音频GameObject管理不善，会导致各种问题轻则Wwise内的功能异常或失效，重则在游戏引擎开发层面留下隐患。3、以GameObject为单位管理音频是Wwise独有的么？有什么特别之处？以GameObject

3、为单位（Object-based）管理音频并非Wwise独有，也存在其他音频引擎（或音频管理器实现）支持这一管理方式。Wwise Event、GameObject与UE Component的关系梳理为了方便理解GameObject的重要性及其工作原理，我们以一个最简单的蓝图接口实现为例，看一下GameObject是如何在代码层面被创建和引用的。由于Audiokinetic（Wwise的开发公司）官方维护有一套功能丰富的Unreal引擎集成，因此Unreal引擎集成当中对于Wwise的SDK的用法具有一定的代表性，故而笔者在此处以PostEvent蓝图接口为例来论述。以下截图为Unreal中Po

4、stEvent蓝图节点的C+代码：Unreal中Postevent蓝图节点定义：该段代码对应该蓝图界面：该蓝图节点上AkEvent和Actor两个输入点必须连入变量或具体的值，否则将会在编译时报错。代码逻辑简单讲就是：运行PostEvent节点时会给指定Actor对象的RootComponent层级附加AkComponent附加AkComponent的过程，首先遍历当前Actor的子级:如果已有AkComponent则直接启动，如果没有，那就新建一个AkComponent：然后AkComponent会通过类别转换和Wwise内的GameObject进行强绑定。所以，每个Actor播放Wwise

5、的声音时，AkComponent必须存在。AkComponent的作用：AkComponent就是存在与UE中的Wwise专用的GameObject（的容器），其可以调用到以下函数：纯看代码可能不方便部分没有代码基础的同学理解相关概念。接下来我们换一个更加通俗易懂的方法来描述下这个逻辑：游戏引擎使用音频中间件播放声音的逻辑是这样的：总结（第一节）（Wwise中的）GameObject的数据来源是游戏引擎中的AkComponent，且该来源不可或缺。（数据可能包括方位、转向、GameSync等等信息。）可以说每个声音的播放都指向了一个目标对象AkComponent。Wwise会为目标对象注册一个

6、与之匹配的（Wwise中的）GameObject来承载声音，其基础属性全部从AkComponent继承。所有的以AkComponent为目标对象Post的Event都是以该（Wwise中的）GameObject为目标的。如果使用一个感性的说法：（Wwise中的）GameObject就是某个人（AkComponent）在声音世界的分身，负责承载所有指向这个人的事件。另外，（Wwise中的）GameObject除可依据AkComponent被注册，也可被解注册。明白了这些以后我们可以做什么呢？1、什么是Event-based音频管理早期的游戏音频中间件或者小体量游戏的音频管理器实现基本都是以Eve

7、nt-based的理念来管理游戏中的音频的。而现如今，通常游戏中的每一个声音都是一个独立的对象。偶尔会有一些接手音频开发的同学在缺乏考虑的情况下选择简单粗暴的方式来实现音频播放的管理与控制：我在本文中将他们统称为基于事件的（Event-based）音频管理。之所以这样划分，是因为他们在实现时通常只考虑了声音的触发，并没有考虑到声音在触发后进一步进行控制的必要和复杂性。尽管上述对象的创建和管理模式存在一定的合理性，但它们肯定是不能满足所有开发需求的。先来看一下第一种方式（一个事件伴随一个随机对象）：稍有编程功底的同学们都知道，游戏中对象的创建和销毁是需要占用系统资源的，低频率事件可以使用该模式，

8、如果是高频触发事件，那么将会在短时间内大量的创建和销毁对象，会导致不必要的系统消耗这是Event-based模式在性能消耗方面可能存在的隐患。当然某些场合可以采取创建对象池的思路来优化，但并不是所有声音的播放都适合指派到随机的对象上。如果我们的游戏中存在多个对象同时触发相同声音的情况，那么Event-based模式将很难精细的管理这些声音，因为所有的Event都是相互独立的，音频引擎无法区分哪些Event属于游戏里的哪个对象。这导致在进行发声数上限等音频管理时就只能进行全局管理，也就是只能使用Wwise中的Global模式进行管理。再来看一下第二种方式（大量事件指向同一个对象）：通常在游戏对丰

9、富的声音设计提出需求的情况下，设计师本身也要将性能的控制考量进去。而将所有声音分配至同一个游戏对象的做法，会导致以实际游戏内对象为单位的更细致的声音并发控制无法实现（与第一种方式一样会遇到这个问题）。若此时还对此同一个音频对象的声音并发量设置了上限（Global），则可能导致声音被随机误伤，进而产生不合理的听感。而若要解决声音被误伤的问题，就需要解除声音并发量上的限制，而这又会导致较大的性能消耗。总结（第二节）Event-based音频管理是将GameObject视为Event的附属物，为每个声音事件匹配一个GameObject的做法。而Object-based音频管理则是将Event视为Ga

10、meobject的附属物，先注册和游戏中对象对应的（Wwise中的）GameObject，然后Event作为子项继承Gameobject的相关信息的做法。为了更方便大家理解，我们此处直接使用一些工作中可能会接触到的案例来进行分析：假定我们当前正在开发的游戏中并没有加入Object-based的理念，依然基于Event-based的理念来触发和管理声音，那么Wwise将不会正确接收和游戏内对象对应的GameObject信息，而是盲目的为每个音频事件独立生成GameObject。那么我们在使用Wwise时可能会遇到以下问题：1、Wwise内所有和GameObject相关的功能全部失效或表现异常具体

11、会如何混乱，参见下图：2、产生不必要的系统消耗以玩家的脚步为例：再以一辆车为例：若车的引擎、胎噪、风噪彼此是独立事件触发的，它们都需要读取车辆的车速。虽然这个消耗可能依然不算大，但是这也是一个不健康的状态。3、针对GameObject设置的插件反复实例化这个前文已经提到过一次，因为每个声音都是一个独立的object，所以每有一个声音都会实例化一个新的插件，每个插件都有自己独立的运行参数，而不是从属于同一个GameObject的插件拥有相同的参数。4、限制了虚实例技术的使用因为不能独立注册和销毁GameObject，也没有办法通过让多个发出相同声音的发声体只实例化其中一个的方式来减少系统消耗，所

12、有的发声体都将是真实实例化的。总结（第三节）如果大家在工作中遇到了类似以上所述的情况，可以尝试查询一下游戏内针对音频的GameObject的创建和注销机制是否正常。有可能有助于大家定位问题产生的原因。1、游戏开发初期应当规划音频对象池，对于可能高频重复触发的声音事件采用对象池技术管理，甚至所有的音频对象都采用对象池技术进行管理。2、游戏开发时除了规划声音的触发和停止机制以外，还要注意规划声音所属GameObject的创建和销毁（引用和解引用）时机。3、游戏引擎的音频接口开发时应注意尽量保持和Wwise官方SDK的参数设置保持统一，必要的时候给Wwise开发独立的音频接口。4、进行音频中间件的更换或升级时应注意新旧中间件SDK的兼容度。如果兼容度低，升级过程中可能需要开发新的音频接口和同时修改声音的挂接逻辑。以上就是截止目前我们对于音频Ga