使用Unity5开发手游，使用FMOD或wwise音频插件而不是自带的声音系统有哪些好处？

使用Unity5开发手游，使用FMOD或wwise音频插件而不是自带的声音系统有哪些好处？

https://www.zhihu.com/question/61882604

碰巧对Unity里的声音脚本，FMOD和Wwise都比较了解，强答一下。音乐和音效还得分开说，因为这两个很多时候需求和设计很不一样。

 

首先，简单的2D游戏大部分时候是用不到这两个中间件的，除非是音乐游戏。而3D游戏尤其是第一人称视角的游戏中就比较有必要。中间件最强大的地方在于自带的那些效果器，用于3D音效的空间处理，这点在沉浸式体验的游戏中非常重要。FMOD和Wwise中带有各种DSP的实时运算处理插件，用于声音在真实场景中的渲染，而Unity引擎中除了加一个Low/High Pass Filter和非常基本的Reverb之外几乎没有任何可以控制的地方。FMOD拥有天气环境音效的生成器，Wwise还带有一些物理建模的插件来模拟挥舞声、风声和击打声等，可以为游戏节省一些资源空间。如果要做AR/VR的游戏，就更加需要中间件进行空间化处理了。据说Wwise现在在开发智能分配通道的功能，也就是说不管玩家的播放设备是什么样的，单声道/立体声/5.1环绕声/VR也好，都能将当前声音在声场中的位置自动分配相应的音量到每个通道上。

在音效上，最让程序员头疼的就是资源管理。音效师做出来的资源往往只有自己才能数的清，程序员在不进行大量沟通的情况下很难理解每个子文件夹都是做什么的，这点对于大公司的开发团队尤甚。举个例子，当我需要做某个怪物的脚步声的时候，哪怕是最简单的随机选取不重复机制，如果在Unity里直接写，都需要先把某个精确路径下的文件载入到一个AudioClip[]里，然后随机选取再检测确认与上一个不重复。还需要考虑一个AudioSource同时只能播放一个AudioClip，如果声音的尾巴比较长的话，会打断，所以可能还得放多个AudioSource，或者根据之前的脚步声有没有播放完来决定是否Instantiate另一个AudioSource然后等到播放完再Destroy。这些在程序上实现并不难，但是很烦人，也可能会产生bug。不像动作特效上的bug一眼就能看出来，程序不懂音频技术还不一定听得出音频上的bug，最后给项目开发带来很多额外的工作量，影响开发效率。而且，我就没见过几个程序员戴着耳机工作的。

还是脚步声的例子，如果我要做出不同的怪物在不同的地面上发出不同的脚步声，以上工作量就大得多。但是如果使用中间件，尤其是Wwise的话，程序员只要做一个简单的Raycast然后把结果对应相应名字的Event就行了，几十行的代码简化成了一行。所有的这些随机/避免重复/不同怪物/不同地面/voice数量等等都不需要程序员来考虑，交给音频设计师在中间件里完成就行了。中间件对于音效带来的另一个好处是能够对不同声音事件进行优先级判断，砍掉不重要的声音或者音量太小的声音，提高游戏性能优化。这个在Unity里虽然也可以做到一些基本的，但可控性比较弱。

另外就是声音的动态变化。Unity居然不支持最简单的声音淡入淡出，需要专门去写一个Coroutine。比如赛车游戏中引擎的声音，往往有很多个样本文件，在不同转速下进行cross fade。在Unity里面要实现这个无缝渐变是比较困难的，但是在中间件里，只需要程序员把引擎转速的变量与FMOD中的parameter或者Wwise中的RTPC在Update里面进行赋值对接就行了。

还有一点就是对于资源包的管理。不管是配乐还是音效，导出的原始文件都是wav格式，占用大量体积。而FMOD和Wwise里都可以针对不同的平台进行不同格式以及大小的压缩。Wwise甚至能够对每一个音频文件自动检测可承受的压缩范围，以保证资源包的最小化，这点在手游上尤为重要。在游戏运行过程中，中间件也可以选择针对不同的音频进行不同的预处理，如常触发并需要快速反应的音效就载入内存中，音乐和环境声就从磁盘上stream，这一点优化是Unity做不到的。不管是FMOD还是Wwise，都能够跟Unity直接连接，通过Profiler来实时查看音频部分在游戏中CPU与内存的消耗，以便进行更好的优化。音频设计师也能够更方便的测试自己做出来的声音在游戏里不同情况下的播放究竟是什么效果。

 

说完了音效来说音乐。如果只是播放一个BGM的loop，是用不到中间件的，但是现在讲究点质量的游戏都会进行动态音乐或者互动音乐的设计，而这一点在Unity里是没有任何技术支持的。我曾经自己用C#写过动态音乐判定的播放规则，包括分层播放以及段落转接。虽然不是非常复杂，但毕竟音乐和程序都是我自己写的，不会有沟通理解上的困难。在大多数现实情况中，程序员不懂音乐，音乐人也不懂程序，如果不用中间件，很难完美地完成音乐人想要的播放效果。

在手游上，尤其是休闲游戏中，许多音效是音乐化的，这就在触发时间上有了要求，我们叫做stinger。比如玩家在吃掉一个物品获得技能时，在音乐中插播一小段旋律或者鼓点。在Unity中无法做到让这些stinger卡在节拍上，除非专门去算每首音乐的节拍换算成每一拍的毫秒单位，然后加一个计时器进行除余（程序员听到这么复杂的需求很可能就觉得算了懒得弄）。

更复杂的是音乐段落之间的对接。音乐文件往往要留着最后的尾巴，因此时长比实际音乐的时间长。如果不留有尾巴，就会听到“噗”的一声，音乐好像突然被切掉了。在音乐之间切换的时候，如果不用中间件，程序员必须知道实际音乐的精确时间长度，而无法通过简单的AudioSource.isPlaying来判断是否进入下一段音乐。在FMOD和Wwise中，这个问题都可以非常简单地解决。Wwise还带有Pre-entry功能，让音乐开始前的前奏提前播放，达到更加智能的播放效果。

Wwise在音乐上的探索还远不止简单的播放分层/段落等方法。在算法生成音乐上都有了技术上的尝试。音乐人在编曲的时候先写好MIDI音符，再通过MIDI音符触发对应的采样文件来生成音乐。游戏的高互动性决定了这种预先写好的音乐是不够动态的。在Wwise中，能够支持简单的采样器功能，将音符采样导入，然后根据不同的游戏状态播放不同的音符。未来我们很可能会见到旋律永不重复的音乐游戏，就是通过这样的技术来进行音乐的动态生成，只要音乐人提供一个算法并将控制点与游戏中的参数对应。这对于绝大部分游戏而言是用不上的，但是中间件为这样的游戏设计提供了可能。如果在游戏中单独写一套AI作曲系统，开发的难度和工作量可以单独做一个游戏了。

 

最后，说白了，对于中小规模的手游，使用中间件更大的好处是让本来就不多的程序员从音频部分中解放，只需要负责游戏本身的开发就可以了。本身小制作成本的游戏使用中间件也花不了多少钱，但是为程序员节省了大量的时间来重新造轮子，也让音乐人/音效师对自己制作的东西有更好的把控。对于大型游戏而言，中间件能做到一些Unity本身无法做到的功能，同时在音频的资源管理上省去了很多扯皮的麻烦。

 

【欢迎关注我的微信公众号：用耳朵玩游戏，分享游戏音频的知识与资讯】

编辑于 2018-06-29

岳豪

游戏音频设计师、技术音频

作为一名游戏音频设计师，这个问题被问到过很多次。几句话很难说清楚，正好趁这个机会写下来。希望越来越少的设计师会被问到这个问题。（FMOD、CRIWARE我都不够熟悉，以下只从Wwise的角度说。）

Wwise里面有很多很炫酷的功能，有些可以增强声音的交互性、有些可以提高声音的表现力、还有些可以提高设计师的工作效率。但是介绍这些功能的时候，往往被程序员一句“手游用不到这个”呛得半天说不出话。

 

确实，在使用了Wwise的手游项目中，我们也仅仅使用了它很少一部分功能。但其中的一些功能，即使是对于手游来说也是绝对不可缺少的。

1、用Event封装一切

对于Wwise来说，Event不只是一个AudioClip，而是一个或多个Action。这个Action可以是播放、暂停、停止一个SoundObject（一个SoundObject可能是多个wav文件），可以是控制某个声音插件的参数来实现某种复杂的声音效果，还可以是内部封装的某些操作，比如切换混音状态。这些Action有些只需要了解播放逻辑就可以完成，还有些必须了解数字音频技术、效果器处理、混音理论才能够完成。把这些操作全部交给程序员是不现实的。在Event封装之后，程序员只需要在正确的时机调用PostEvent就好，完全不需要了解Event内部究竟发生了什么。

2、音频工作站级别的总线控制

总线（bus）这个概念对于非音频专业出身的人来说可能有点陌生，这里我不打算详细的解释这个概念。我们可以直接从应用的层面来说明为什么总线对声音很重要。

首先，最简单的，我们希望在游戏中，音乐、音效、语音可以分别设置音量大小及开关。借助总线可以非常方便的实现这个功能。当然，即使没有总线，程序实现这个需求也不是非常复杂。

那么，进一步的。在游戏进行的过程中，有时会播放CutScene。很多游戏中，CutScene是通过在游戏摄像机前又盖了一层2D画面实现的。那么这个时候，有一个新的需求。如何让玩家只听到CutScene的声音，而屏蔽掉被CutScene覆盖的游戏画面中正在发出的声音？到这一步，程序就很难实现了。因为程序很难判断哪些声音是在CutScene中发出的，哪些声音是在游戏场景中发出的。而Wwise依靠总线依旧可以非常方便的实现这个需求。

接下来。对于声音设计师来说，声音是有优先级的，而声音的动态范围是有限的。玩家不可能听到所有的声音。Boss的技能总是要被听到，而小怪技能的声音优先级可以稍微低一些，玩家的脚步声只有在非常安静时才听得到。基于总线的混音功能可以满足这个需求。优先级高的声音在触发的时候可以动态的压掉优先级低的，使得在任何时候，玩家都能够听到设计师想让玩家听到的东西。很多缺乏混音处理的游戏，听起来杂乱无章没有重点，往往就是这里没有做好。

针对总线最大发音数限制，是性能优化中非常有效的一步。王者荣耀还在这个功能的基础上加上了RTPC控制，可以根据手机的性能、是否处于卡顿状态等情况动态修改限制的数量。到这一步可以说，没有中间件，是绝对无法完成这些需求的。

3、专业的音频插件

虽然手机性能有限，用到的效果器种类比较少，但是基础的混响及限制器还是会被用到。越来越多的专业效果器被集成在了Wwise中，一个好的效果器能够让游戏声音表现更上一层楼，而差的效果器足以毁掉设计师全部的心血。

除了效果器，我想重点说一下Wwise里的合成器。像饥荒这样的游戏，里面60%的声音可以通过合成的手段来完成。比如说背景的风声，火燃烧的声音，采集的Whoosh声。（虽然饥荒本身可能并不是这么做的。）声音合成相比传统的素材制作最大的优势是听感不会重复、零资源量、可以更多地和游戏中的参数联动。比如风声可以通过程序定义风速的参数从而控制风声的表现，这个风速还可以影响游戏中树的摇摆，使美术和声音的体验更统一。

相比数字音频工作站中的音频插件，Wwise内集成的插件可以获得更强的交互性。所有插件的参数都可以根据游戏中正在发生的事件平滑的更改。

想要了解更多可以参考Wwise官网。

Audiokinetic Plug-ins | Audiokinetic

4、交互音乐系统、打断机制以及3D衰减

对于手游来说，很多地方的声音设计都有所简化。但是音乐系统和UI系统，这两者相比端游是丝毫没有简化的。交互音乐系统、打断机制、3D衰减这三个功能放在一起说，是因为仅从功能上看的话，这三者交给程序实现起来难度都不大。但是其中隐藏了巨大的沟通成本。

A音乐到B音乐切换时要播完当前小结再切换。B音乐到C音乐要立即切换，中间要做交叉淡化，Fade In 0.3s、Fade Out 0.5s。一个RPG手游，这样的音乐切换点有几千个。这些全让程序来做？那收到的结果一定是一切换音乐，就听到“咔”一声。

游戏中人物的对话，要后一句打断前一句，或者根据不同的人物分别设置不同打断。在战斗中，需要动态的触发一些对话，这里就要求前一句还没说完的情况下，后一句不能打断前一句，并且后一句不能和前一句同时播放。（崩坏3战斗中，战斗中触发的对话频繁被打断，个人认为这里的设计不够好。）

3D衰减也一样。要根据怪物体型、是否是boss，特效表现设置不同的3D衰减范围。Unity自带的音频系统好像有这个功能，但是并不能像Wwise中，通过