前言
市面上存在许多游戏互动音频解决方案，有时也被称为音频引擎。其中，Wwise的接入项目已经非常多——在国内，大家熟知的《王者荣耀》、《QQ飞车手游》及近期各大公司推出的众多重度手游中，都可见Wwise的身影。
我将借本文分享一些自己作为项目中负责音频的程序员在开发过程中获得的经验，供大家参考。
设置开发规范
无论使用多么优秀的工具，都应意识到“无规矩不成方圆”——工具使用规范的制定与遵循有利于开发、迭代和维护，还能降低自动化环境的介入成本，减少团队之间的工作流程的冲突，提高协作及迭代效率。
- SFX对象的命名可以根据其所属模块、大概用途、与游戏内资源相关性、播放逻辑等等作为分类，如“用于ABC模块中UI的Title界面的点击（Click）的单次播放（OS）声音”，名称可设为——ABC_UI_TitleClick_OS：
这样做将便于开发者快速的辨别音频类别及使用情景，从而提高迭代效率。
- 具备复杂播放逻辑的事件，需要在Notes中对设计进行说明。
如图所示，通过Event实现的音频功能是非常广泛的，为方便后续团队工作，在户必须播放复杂的声音播放逻辑设计的时候，应在 Notes 里进行简要的说明——不仅是给自己看，也方便之后遇到问题进行定位。
- GameSyncs 需要在 Notes 里说明其用途并简要说明驱动逻辑。
- ShareSets 应根据业务相关性（用途）进行命名，以便于他人更好地对已有资源进行复用，且便于管理。
版本管理
对于版本控制，继尧姆.雷诺已经有一篇非常好的文章，可以移步至 https://blog.audiokinetic.com/zh/version-control-a-wwise-project/ 仔细阅读，在此我只列举最核心的要点，以方便大家据此快速创建ignore列表（也是为了方便大家理解项目中存在提交规范的原因）：
建议进行版本控制的文件
- File Manager（工程中Project -> File Manager（快捷键：Shift+F1））页面Work Units栏内列出的所有文件都应该受到版本控制。
- Originals 文件夹用于存储工程项目所用到的原始音频文件，因其为构建Soundbank所必须，故建议添加到版本控制中。
建议忽略版本控制的文件
- *.validationcache ——记录经过验证的所有工程文件列表，加速Wwise启动的文件；
- *.wsettings ——为当前工程定义的默认转码和杂项对象设置。这些设置会按各个用户分别保存；
- IncrementalSoundBankData.xml ——SoundBank构建的增量标识文件，记录内容变更的时间戳；
- .cache ——顾名思义，工程的缓存文件；
- *.akd ——Wwise工程的相关数据 & WAV文件的音频相关元数据，会自动生产以及变更；
- *.prof ——ProfilingSession相关数据信息；
下图展示了使用svn进行版本控制时，Wwise工程看上去的样子：
使用WAAPI建立自动化流程的大致思路
WAAPI简介
WAAPI 的作用原理是通过网络在不同程序之间传输信息包，由此实现运行WAAPI客户端的程序与 Wwise 间的双向通信。它采用了支持多语言编程的 WAMP 通信方式（ Web Application Messaging Protocol，即 Web 应用程序消息传输协议 ），因此我们可以使用不同的语言编写 WAAPI 代码，并自由地选择通过本地或网络与 Wwise 进行通信。
建立自动化流程的目的
通常游戏项目中会有成百上千的声音资源（AAA级可能会有几万甚至几十万），而声音设计师为了追求极致的声音表现，会需要对每个声音声音进行精确控制与复杂配置，若没有有效的生产工具用于在某些应用场合进行批量处理，工作将难以进行。为此需要为他们建立自动化流程，恰巧WAAPI能够帮助我们实现这个目的。
建立自动化流程并引入到项目中可有效地减少重复劳动、解放生产力，提升团队成员工作产出的正确性，从而实现对团队整体产能及价值的提升。
使用WAAPI能够实现的自动化流程：
- 开发者向版本控制仓库推送工程变更信息（辅助版本管理）；
- 版本控制系统（Git 、SVN）监听相关OnCommit事件触发 CI系统（Jenkins、travis）（进一步优化持续集成管线）；
- 开发者结合WAAPI编写自己的逻辑脚本进行相关逻辑的触发（技术音频设计师可以便捷地开发团队成员需要的工具）。
使用WAAPI可以实现的设计工具：
- 批量自动导入音频文件的工具（如WAAPI Transfer）；
- 批量创建 Event；
- 大规模修改属性/转码设置；
- 管理SoundBank的生成；
- 按照游戏业务需求自动化填充配置表信息（批量重命名/根据名称配置属性等）。
如何处理第三人称视角摄像机的转向
通常的AVG / RPG游戏画面都是由第三人称视角的摄像机来进行渲染的，然而游戏中是角色作为听者去“听”或渲染游戏中的声音，由于Listener也是有指向的，所以假如摄像机指向了游戏中的一台收音机但是角色确是背对着收音机的，那么我们会听到收音机在脑后发声……这可以理解但很难接受。
针对此类问题，有不同的解决方案。
角色与摄像机的位置及转向关系
以下是我用于解决此类问题的代码，在 GetForward 函数中，将相机的朝向同步给AkGameObj，进而AkGameObj将位置信息同步Wwise引擎。
另外推荐大家阅读Sanjay Madhav所著的《游戏编程——算法与技巧》一书中关于第三人称摄像机设置的内容，那是更加理想的解决方法。
SoundBank管理
在Wwise中，有两种类型的SoundBank：
- Initialization Bank : 一个特殊的Init.Bnk文件，包含了Wwise工程所有的信息，例如：总线结构、State、Switche、RTPC。这个文件会在Wwise每次生产Bank文件时 自动 重新生成。 该文件必须要使用其他Bank之前加载，否则其他Bank将无法正常解析。（可以理解为有基础依赖）
- SoundBank ： 此类*.Bnk可以存储事件的详细信息、音频、其他插件所需要的数据结构。可以简单理解为是一个 数据存放的容器。该文件可以在运行中自由的控制加、卸载。建议要将Wwise接入到项目的程序员朋友仔细阅读Wwise Help文档第35章关于Soundbank管理的论述，传送门：https://www.audiokinetic.com/zh/library/edge/?source=Help&id=managing_soundbanks
如何合理的组织Bank以及规划Bank粒度
通常这个问题和如何规划 Unity 的AssetBundle的问题很相似，管理方式也大同小异。
资源的规划和组织的粒度，需要依据项目类型、具体设计思路以及采用的技术来思考如何做到该项目最优。
资源（Soundbank）组织划分的依据：
- 具体业务分类——例如：英雄、UI、3D环境声、剧情、敌人（包含怪物、Boss）等等，这个分类方法将根据项目的不同而有所变化，且受具体游戏机制设计的影响；
- 生命周期——例如：背景音乐及2D环境声会在很长时间中持续存在于游戏中，需要采取不同的资源读取策略。
甚至可以创建进行数据采集的程序进行分析，从而为游戏给出资源组织和规划的动态规划最优解。
官方文档中Soundbank管理策略一章也有很好的介绍，传送门：https://www.audiokinetic.com/zh/library/edge/?source=Help&id=strategies_for_managing_soundbanks
以上便是这次分享的全部内容，有需要讨论的小伙伴可以点赞，关注，互动～
评论