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

碰巧对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本身无法做到的功能，同时在音频的资源管理上省去了很多扯皮的麻烦。

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