为什么使用游戏音频中间件？

　　图中是笔者设计完成的一个相对较为复杂的交互音乐，可以看到运用了上述几乎所有的标记，以及parameter，这是一个完全无缝的交互音乐设计，但从功能上来说运用了Fmod的交互设计内容，看似复杂但如果理清播放规则，可以很有逻辑性的完成设计制作。

　　Fmod在交互音乐的过渡中相比Wwise和CRI-ADX2少了一个同时播放的过渡，例如白天和黑夜的切换过程，一般同一个地区的白天和黑夜，音乐设计上是只改变配器不改变其他，因此如果同时播放，到达时间点按照小结进行切换会非常平滑，而Fmod中不具备时间同步切换的功能。

　　3·Wwise

　　Wwise现阶段在国内的发展迅速，从腾讯大批量使用Wwise后，Wwise在国内音频的普及量得到了迅速的发展。

　　Wwise的界面如下：

　　wwise和ADX2以及Fmod的界面差别较大，没有类似DAW式的编辑区，取而代之的是各个参数图形，这使得wwise的理解和学习相对于Fmod和ADX2稍微有一点难度。

　　Wwise工作原理

　　声音设计师设计制作完成素材文件后，将素材文件根据播放规则放在wwise编辑器中的各种Container中，而后将各个Container放在Event中，并将Enent指定到Bnk中，并生成Bnk文件，Wem则是选择使用流播放后生成的文件。将Bnk文件交付程序员后，程序员根据Bnk和Event名称来播放音频。

　　Wwise包含大量的Container，这决定了基础播放规则

• Random Container随机播放容器
• Sequence Container顺序播放容器
• Switch Container条件播放容器

• Blend Container混合播放容器

　　这些容器可以相互混合使用，使得播放效果可以各种嵌套，有着非常大的灵魂性，类比于Fmod的Event嵌套，Instrument嵌套以及ADX2的Cue嵌套，他们都提供了强大而灵活的播放规则设计。

　　Wwise针对参数做了三种类型，RTPC，Switch和State，他们其实都是参数的范围内，只是RTPC是连续变化的，而Switch和State则是跳变的状态转变，不具备连续性。对于Switch和State的区别则是：State是全局变化，而Switch是单个变化。

　　简单来说就是State变化后，整个游戏和该State挂钩的会全部变化，而Switch变化时则时该event单独变化不影响其他。

　　RTPC：

　　State

　　在交互式音乐层面，Wwise则使用独立的交互式音乐设计方案，他与其他音频设计位置不同有专用的Interactive Music Hierarchy。

　　如图所示：

　　这里通过构建Switch和State作为播放条件设计填充了整个音乐播放架构，在Transition中进行转变的设计，从而达到无缝切换音乐。

　　使用思路上Wwise利用了原本的State和Switch作为条件管理整个音乐播放规则。

　　图中展示的就是通过条件来完成的播放规则内容。

　　Wwise除了征程Event外还提供了一个新的功能：Dynamic Dialogue动态对话。

　　以一个正常多选择向游戏，当玩家选择不同的对话时需要有不同的音频内容来播放，Wwise的Dynamic Dialogue动态对话功能就为这种音频设计提供了方便

　　图中所示的就是一个动态对话的应用方式，他类似于交互式音乐设计也是通过Switch和State作为条件决定最终的播放内容。

　　4·综合

　　CRI-ADX2，Fmod和Wwise各自的界面应用方式不同，但他们都能为设计者和程序提供方便以及提供更强大的设计效果。

　　除上述简述的内容外，三个引擎都支持2D，3D效果，DSP（Wwise中称之为Bus），以及各种各样的Plug-in，他们的各自功能并非以上内容能够涵盖的，且在使用上由于都具有各种应用效果，嵌套等可以实现多种多样的需求。

　　简述三个音频中间件没有任何对比的意思，只是各自用法不通用，实际用哪一个要看读者自行选择。

　　结语：

　　音频中间件的引入极大的优化的音频设计，降低了效果实现的难度，同时也为更好的沉浸式音频做好了技术支持。

　　笔者致力于研究音频中间件，音频中间件的内容之多绝不可能一文即可全部讲述完毕，三个音频中间件各自的用法也会在后续过程中逐渐向大家介绍。

　　最后也希望国内游戏的音频能够达到最高级的水准。

　　来源：腾讯游戏学院

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!