使用Unity5开发手游，使用FMOD或wwise音频插件而不是自带的声音系统有哪些好处？
使用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本身无法做到的功能，同时在音频的资源管理上省去了很多扯皮的麻烦。
【欢迎关注我的微信公众号：用耳朵玩游戏，分享游戏音频的知识与资讯】 作为一名游戏音频设计师，这个问题被问到过很多次。几句话很难说清楚，正好趁这个机会写下来。希望越来越少的设计师会被问到这个问题。（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 | Audiokinetic4、交互音乐系统、打断机制以及3D衰减
对于手游来说，很多地方的声音设计都有所简化。但是音乐系统和UI系统，这两者相比端游是丝毫没有简化的。交互音乐系统、打断机制、3D衰减这三个功能放在一起说，是因为仅从功能上看的话，这三者交给程序实现起来难度都不大。但是其中隐藏了巨大的沟通成本。
A音乐到B音乐切换时要播完当前小结再切换。B音乐到C音乐要立即切换，中间要做交叉淡化，Fade In 0.3s、Fade Out 0.5s。一个RPG手游，这样的音乐切换点有几千个。这些全让程序来做？那收到的结果一定是一切换音乐，就听到“咔”一声。
游戏中人物的对话，要后一句打断前一句，或者根据不同的人物分别设置不同打断。在战斗中，需要动态的触发一些对话，这里就要求前一句还没说完的情况下，后一句不能打断前一句，并且后一句不能和前一句同时播放。（崩坏3战斗中，战斗中触发的对话频繁被打断，个人认为这里的设计不够好。）
3D衰减也一样。要根据怪物体型、是否是boss，特效表现设置不同的3D衰减范围。Unity自带的音频系统好像有这个功能，但是并不能像Wwise中，通过Audio编组加上Share Set功能方便的实现。
以上功能只是简介绍了Wwise在手游开发中一定会被用到的功能，并没有完整的表达Wwise的强大之处。Wwise里有些功能，例如基于采样的粒子合成系统，可以做汽车引擎声。这种声音的需求只有通过中间件才能实现。
此外，理论上能实现和实际上能实现的差距很大。由于声音在游戏开发过程中优先级很低，很多时候，一个很简单的功能，直到游戏上线也还没有实现。程序员的工资挺贵的，把这个钱省下来买Wwise授权大家都开心。（请把软文钱打我支付宝）
--------------------------------------------------------------------------------------------------------
以下是一些私货
前面有答主提到，音频中间件可以将程序员和设计师的工作分开，程序员只关注逻辑，设计师只关注表现。这个是非常对的。我们团队更进了一步，自己有技术音频，可以完全不依赖项目组的协助完成全部的音频开发工作。项目组只需要提供项目的SVN地址，其余的可以完全不考虑。
这样做的好处是显而易见的，声音团队可以百分之百的掌控游戏声音的所有问题，包括故障排除、性能优化部分。阴阳师、崩坏3这两款游戏都是用了中间件的，然而依旧有较多声音方面的bug，并且好几个版本都没有解决。（比如阴阳师即使在设置里关了声音开关，还是能听到开场动画的声音。崩坏3很多技能在被打断时，声音还是会继续播下去。开放世界的音乐总是错误的被切换。）这些bug大多发生在程序员和音频设计师对接的中间地带，这些问题对于程序员和设计师都存在盲区，加上声音问题优先级低，所以导致很多问题长期无法解决。另外，在传统开发流程中，程序员开发的音频编辑器使用起来非常不顺手，某些机械重复的步骤会占用设计师大量时间。我们自己开发配置工具后，这个问题也很顺利的解决了。
这样的开发模式已经持续一年了。几个工作室的几十个项目组普遍对这种模式表示满意，设计师也能完全实现自己的想法。后面有机会的话，我会分享我们团队的一些工作流程、开发经验以及提升效率的工具。 用的不很多（我一般小型项目比较多，音效要求不复杂）
最近有个AR项目用的FMOD，因为本来就是音乐游戏，总的来说Fmod或者wwise的好处还是在于功能比较强，比较接近音效师本来使用的软件，而且分工比较方便。
有些类似随机播放时间，多个音效clip循环等等的，氛围音效无缝衔接等等，确实是unity本身无法实现的。
比方说类似《巫师》那种音效，有人声，有氛围音乐，这种就不是一整段乐曲可以解决，都是将音乐做成不同的片段，根据当时的状态逻辑决定每一段如何衔接，这就有点随机作曲的意思在，是非常高级复杂的玩法，必须得上fmod或者wwise了
但是，FMOD的文档真是喂了狗了，里面啥都没有，我花了小一个月，请各种音效朋友们吃饭，才搞定一个最普通的load和播放。 之前研究过一阵Wwise，感觉最大的好处就是使用这些第三方工具，音效的制作可以脱离引擎本身，也就是音效师根本不需要去了解UE4或者Unity的逻辑，程序员只需要关心逻辑本身而不需要懂音效。
比如做一段飞机的音效，随着距离衰减要在好几个不同的音效之间进行crossfade，在引擎里做的话可能就得需要程序来介入，去调参数等等，工作分离出来之后只需要给音效师一个距离参数，各个音效的衰减曲线就可以很直观的在这些软件里看到了；还有一些需要random或sequence的音效逻辑制作也很方便；做一些特效混响也不难。
如果你的项目音效比较复杂，并且有外包或者专门的音效师，那么建议使用这类的插件；如果只是小项目，不需要带参数变化的音效，大部分音效直接扔进场景就能解决的话，还是用引擎自带的就好，用插件反而增加了麻烦。 首先，在性能方面，Wwise/Adx2/Fmod等音频中间件都针对优化性能做出了很多努力，提供给了声音设计师多种手段，来追求效果/性能两者平衡的最优解，同时又极大的解放了程序端在音频功能支持上的工作量，这些都是Unity原生音频组件所远远不具备的。
其次，在传统的音乐制作领域，为听众呈现出最终的音乐前的最后制作环节是混音和母带处理，这个过程可以为听众带来混音师/母带工程师对听感的艺术理解，同时让歌曲的整体听感再上升一个层次，让没用的频段让位给有用的频段，各个声部的平衡达到理想状态，并在声学角度达到行业要求的标准。那么在游戏音频领域，也同样存在混音这个极其重要的环节，而游戏的交互性则给混音带来了很多不同于传统音乐/影视行业制作方式的区别，而音频中间件的出现，就像Protools/Nuendo/Logic等音频制作软件一样为游戏的实时动态混音带来了可能，可视化的各种模块让声音设计师更直观的掌控游戏音频工程全局。想用Unity做到这一点，真心很累，声音设计师和程序员都累，累完效果还有可能打折扣。混音绝不是针对某个音频样本的效果处理，那是音频编辑/声音设计，混音是全局性的听感考量。
再次，引擎兼容性方面，Wwise/Adx2/Fmod等音频中间件都有着多年的项目经验积累和研发经验，都分别对各个主流游戏引擎提供支持，所以兼容性方面无需担心。同时音频中间件所带来的新的音频/程序协作方式可以极大的解放程序端的工作量，让声音设计师主导音频工作的展开，让专业的人负责专业的领域，优化工作环节，提高工作效率。程序端只需要专注于音频相关功能的开发，而具体的资源解决方案则完全由声音设计师来处理。
至于现在国产游戏越来越多使用Wwise的现象，还有一个重要原因是Wwise官方对中国地区支持工作的重视和相关汉语资源的出现（感谢Wwise的北南老师和施飏老师），可以说在某些方面确实领先了同类的Adx2/Fmod等产品。
最后关于游戏引擎原生音频模块方面，Unreal的Blueprint系统和Procedural Audio相关功能应该是领先了Unity，Epic Games的两位音频程序员Aaron McLeran和Dan Reynolds为Unreal带来了很多新的音频功能，今年的GDC也有一场专门的宣讲会，讲解并演示了Unreal Engine 4.16的很多新的features，相关视频：https://www.youtube.com/watch?v=ErejaBCicds
以上回答没有太多的介绍到具体的功能，因为具体内容涵盖面太多不好码字，想讨论相关问题的欢迎私信我~ 由于公司没有音效师，程序和音效bank的制作都是我来，就以实际应用举几个我用到过的FMOD功能说几个。
1.脚步声、武器挥击。可以在一个event中放置多个相似的音效。每次播放都会随机播放一个，甚至可以对每次播放的音效在pitch上进行一定的升降调随机，使音效不单调。而程序上要做的只是调用一下Play()就可以了。
2.bgm。任意设置循环区域就不多说了，更有趣的功能在于，可以踩着音乐节拍进行跳转。比如游戏进行到Boss第二阶段，主歌需要跳转到副歌，只要设置好节拍，曲速和允许跳转的区域，在程序中将相关跳转参数设置到阈值，音乐就会踩着节拍跳转到副歌。
3.其他。Fmod支持大部分daw可以做到的大部分能力（当然软音源和钢琴窗是没的），可以用一个参数控制Reverb的干湿程度的包络线等等。客服的态度也很好，还不收费，在Ps4上也运作良好。
手机打的，暂时说这么多吧。就想想如果以上功能如果都让程序自己实现需要多麻烦吧！还对程序的音频知识都很高的要求。
题主可以下载一个fmod studio，打开里面自带的示例调调参数听一听，就知道这些东西的好处了。 以前4.x版本有个问题在Android音效始终要延迟1-2秒才播放出来，通常情况下没问题，可是在有些时候很致命，必须要及时播放。 当时在网上查喊自己用Java写个接口unity去调用Java的播放不用unity的接口 Unity程序，将Wwise对接到Unity，Wwise就是一些大厂项目在用，Wwise系列教程https://edu.uwa4d.com/course-intro/0/131 用过一段时间的wwise，做以下几个具体功能的时候比较方便：
1.当策划需求一个声音需要随机播放多个随机音源的其中一个时，例如脚步声、普通攻击声，当这类声音一直播放的都是同一个音源的时候，人会产生听觉疲劳。如果使用wwise，客户端只需要触发事件就可以了，至于一个事件怎样去随机一个音效，就是策划管的事了。
2.根据材质播放不同的声音，例如挖掘土地和挖掘金属、挖掘石块要产生不同的音效，这个功能可以让策划配置不同材料的switch名，客户端根据导表信息，自动设置switch，就会播放对应的音效。
3.声音曲线RTPC（real time parameter control），x轴可以是距离、时间等，y轴可以是音量、音调等，曲线是可以拖动调整的，这就产生了一个可以可视化调节的对应关系，而这种对应关系就不需要程序去管了。
4.对全部声音的状态处理，例如在陆地上和水下，听到的声音效果应该是不同的，这个在wwise里可以进行比较简单的设置。
5.对音源文件的内存优化，例如一段较长的背景音乐，可以设置只加载正在播放的那一小片段。
6.交互式音乐，类似dota那种，当战斗的时候播放战斗音乐，战斗结束切换为一般BGM，这是通过触发器trigger实现的，客户端只需要判断切换战斗音乐的时机并触发，wwise会自动根据策划配置平滑过渡。
7.音效播放的各种效果，例如淡入淡出，播放之后停顿几秒继续播放，声音播放几秒之后慢慢变小等，都可以交由策划配置，客户端不用多写代码支持这些功能。
8.多平台支持，多语言支持。wwise支持多个平台，会根据平台不同输出不同的bank文件（一类音源的打包小集合），并做相关优化。当游戏的语音有多个国家语言版本的时候，wwise也能轻松设置。
9.性能监视。
10.动态混响，例如吃鸡这样的游戏，在房间里打狙击枪和在平地上打狙击枪，由于房间内声音会来回反射，所以混响效果应该是不同的。通过游戏过程中，对RTPC实时变量的控制，可以达到此效果。
页:
[1]
2