让我们假设这样一个场景——设计师主导
项目想要在游戏的音频方面进行一些提升，听说Wwise是非常好的工具。然而无论是设计师还是程序员，都不是非常了解如何使用。这时候项目希望设计师能够主导Wwise的接入，但设计师可能是一个一直以来醉心于线性媒体作曲及声音设计的成长中的声音艺术家，尚未做好以声音为武器带领其他队友展开游戏开发冒险的心理准备。
他鼓足了勇气快速学完了Wwise 101认证教程并获得了认证，却发现面对其他队友关于如何热更、如何优化内存/CPU、如何获取源码之类的问题仍然一头雾水。困惑的设计师便想“自己不是程序要如何去寻找这些问题的答案......文档这么多真的全都要读么，设计师与程序员的分工到底应该是怎样的？”
我们再假设另外一个场景——程序员主导
项目想要在游戏的音频方面进行一些提升，听说Wwise是非常好的工具。然而无论是设计师还是程序员，都不是非常了解如何使用。这时候项目希望程序员能够主导Wwise的接入，习惯了自己封装基本播放功能的程序员很自然的想到要去做一下播放、暂停、淡出、完成播放的通知、发声数限制、热更、多语言之类的功能。
程序员问设计师有没有用于这些目的的接口，设计师说他也不清楚，于是程序员就去根据自己的理解开始工作了。没想到忙活了一圈后，被设计师同事告知重造了一批Wwise已经有的最基本的轮子（还被建议学一下Wwise 101认证教程），有种几天的坑踩了精力白费的感觉。苦闷的程序员便想“这文档到底该读哪一部分先（101感觉不是给程序员写的啊）......”
实际上
Wwise所提供的文档资料是足以解决开发者使用过程中遇到的绝大多数问题的。
但之所以大家会遇到上面所说的两种情况，或许与Wwise是一款音频中间件及我们对文档不同模块承担的任务的介绍不够清晰，没有将不同Job Family的完整Wwise启动流程放在更显眼的地方进行介绍有关。
因此我想借写作这篇文章的机会做一个梳理，为使用Wwise的开发者提供一个系统学习Wwise的最短文档阅读路径，让一部分散落在设计师与程序员分工交叉地带的常见问题得到强调，从而让我们的文档更好读。
文章从下载安装开始，一步步指导读者阅读适合自身的文档，更加省时省力，对于新手十分友好～
扫一扫
2957
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
