游戏音频设计入门（中）：工作流和具体分工| 机核GCORES

相关文章推荐

重情义的西红柿 · AAA游戏艺术——由浅入深了解游戏音频技术（ ...· 11 月前 ·

重情义的西红柿 · 游戏音频设计入门（中）：工作流和具体分工| ...· 11 月前 ·

重情义的西红柿 · 游戏音频设计入门（上）：非全面的游戏音频设计 ...· 11 月前 ·

重情义的西红柿 · 游戏音频- UWP ...· 11 月前 ·

为更好地表达游戏音频设计的特点，并与传统声音设计有所区分，我把音频数据（Audio Data）定义为由声音资源（Sound Asset）和实现逻辑（Implementation Logic）两部分组成。其中，声音资源是指在数字音频工作站（DAW）中制作完成并导出、以 Wav 格式为主的声音文件，而实现逻辑考虑的则是与声音资源何时触发与停止、如何变化与传播等相关问题，这两者在游戏引擎中共同组成了所谓的音频数据的概念。

接下来将围绕上述概念梳理一下其中涉及到的一些重要环节。

简单来说，在实现某个具体的设计需求时，考虑的问题其实就是播放什么声音和怎么播放的问题，分别对应的就是声音资源和实现逻辑，这一点是非常容易理解的。

需要注意的是，声音资源和实现逻辑之间的关系是同时从设计需求出发来考虑的、互相影响的平行关系，而非先后关系：不同的实现逻辑会直接影响到声音资源的制作方式，而声音资源的组织形式往往也会影响到实现逻辑的优化。

以枪声为例，枪械射速驱动和固定片段播放这两种不同的触发方式，直接决定了枪声资源是要做成完整单发的形式还是可循环片段的形式，而在枪声层次上的细分也对实现逻辑提出了要求，需要保证各个层次能在同一时刻被精准触发和停止。

这个阶段要做的工作大致可分成两部分：

与游戏设计师和相关工种的同事进行沟通，明确设计需求并制作出相应的声音资源；
清晰明确地将实现逻辑传达给程序员，在游戏引擎中完成相应的功能开发和验证。

完成声音资源的制作和实现逻辑的开发之后，接下来就到了把音频数据在游戏引擎中与相对应的设计元素整合起来共同测试游戏表现的时候了。其中，游戏音频设计师还需要在混音标准和性能指标等方面去做整体性的设置与调整。

在这个阶段，谈一谈我认为比较重要的两个观念。
1. 正如上文提到，游戏音频设计师需与各个工种进行沟通制定具体的设计需求，因此音频数据也会被相应地整合到各个相对独立的功能组件中去，比如地图关卡、动画和特效等，它们之间的整合方式存在着较大的差异。我觉得，既然游戏音频设计师是对最终的声音表现负责，那么音频数据整合作为其中的一个环节，自然就是分内之事，而不应全权交由其它工种同事来处理。另外，游戏音频设计师对整合工作有更多的把控，其实是为自己在后续 Debug 环节的工作提供了更多自主性。
2. 跳出自己作为开发者的角色，尽可能从玩家视角去测试和评价整体的游戏表现。有时我们可能会太过坚持所谓专业上的“正确”，而忽视了玩家体验到的实际感受。比较好的实践方式是，亲身投入到日常的测试工作中去，与开发组同事和参与阶段性测试的玩家沟通，听一听他们的真实想法与感受，我相信一定会有所收获。
测试和评估游戏表现之后，各种问题自然也就浮现出来了，可能是声音资源本身无法匹配视觉元素改动之后的效果，或是实现逻辑不够严谨导致了触发错误，当然也有可能是整体表现不如预期，那么就要回到设计需求的环节重新开始。

在这个 Debug 阶段，游戏音频设计师最重要的能力就是—— 熟练使用各种调试（Profiling）工具，快速找到问题到底出在哪个环节。如果是声音没放出来，首先判断是不是声音资源本身或数据整合上的问题，是的话就自行解决；如果排除这些环节，再从实现逻辑等更深层次的角度去考虑，尽可能缩小出错范围，并将相应问题和调查结果详细表述成非声音专业背景的人也能听得懂的状态，然后再寻找程序员或相关工种的同事来一同解决。

以上就是根据图例所示，以音频数据为核心展开梳理的游戏音频设计工作流。而游戏开发本身有一个特点就是迭代（Iteration），需要不断进行重复性的工序来无限逼近预想的表现效果，游戏音频设计作为其中一环，自然也是要遵循这个规律的。因此上述的工作流其实是自始至终地贯穿在游戏开发的每一个阶段中的。
1. 提供了更有针对性的功能和管线来全方位地管理海量的声音资源，以满足各种复杂且一直在变化的开发环境的要求。同时，某些音频中间件与数字音频工作站之间的联动功能，可以让游戏音频设计师对声音资源进行更加快捷方便地调整。
2. 完成一部分实现逻辑，省去了在游戏引擎中重复造轮子的成本。游戏音频设计师可以在图形化界面的软件中实现某些复杂的音频功能，并在游戏引擎中快速地进行验证与调试。这极大地减少了程序员的工作量，而且也给游戏音频设计师在创意上提供了更多的试验空间。任何有关设计的工作流，很大程度上都是由工具来决定的。虽然工具的更新换代会很快，但就目前游戏开发的框架结构和技术水平而言，本文所讨论的游戏音频设计工作流还是具有普适性的。
在「上篇」中，我大致分析了“技术音频”这一概念出现的原因，也立场鲜明地表达了自己的看法——不要轻易放弃那些原本就是份内职责的技术性思考和解决问题的能力。虽说，这一观点有些理想化，但无论是从音频团队的人才架构还是工作效率来看，技术音频这一工种的出现肯定是有正向价值的。

聊到游戏开发工种的话，技术美术（Technical Artist，简称“TA”）这一概念大家多少都有所了解：一个艺术与技术双修的综合性工种，在艺术表达和技术实现之间架起了桥梁，去解决普通设计师职责范围之外的问题。从称呼上就可发现，技术音频的角色定位其实和技术美术是类似的，即解决普通音频设计师职责范围之外的问题。因此需要讨论的重点是——音频设计师和技术音频之间的职责边界是什么？

我浏览了国内外相关的招聘信息，并结合从同行朋友们那里了解到的实际情况，大致勾勒出了目前技术音频设计师的职责定位和可能涉及到的工作内容：
- 技术音频的职责定位是一个连接者的角色，更好地建立起音频部门和项目中其它工种之间的协作关系。
- 从更全面的角度去管理整个音频项目工程，如制定命名规则（Naming Convention）、搭建音频数据结构（Audio Data Structure）等。他将会更加注重在与游戏引擎相关的部分上——协同设计师和程序员完成与游戏玩法直接相关的音频功能开发，及音频数据整合、功能调试和性能优化等。
- 需考虑工作流程方面的问题 ——优化已有工具或开发新的工具来不断提高整体音频设计的工作效率。这部分工作可能还需要额外的引擎/工具相关程序员来协同完成。
在我来看，技术音频的出现其实是将原先音频设计师的一部分工作内容剥离了出来。在上文中，我提出了“音频数据”这一概念，其中包含了“声音资源”和“实现逻辑”两部分，音频设计师将从这两方面入手去考虑最终的声音表现。而在有了技术音频这个角色之后，声音资源的制作将主要由声音设计师（Sound Designer）来完成，主要关注在声音本身的艺术表现上；而技术音频则会负责相应的功能逻辑，以及其它与技术实现直接相关的工作内容。

细心的朋友可能已经发现了，我把负责声音资源制作的人员称为是声音设计师，而非音频设计师。对于大多数人来说，“声音”和“音频”这两个词在字面意思上其实并没有太大的区别，只不过“音频”一词听起来可能更像是在搞技术。没错，在这里我定义的“声音”是更偏自然化和艺术向的，而“音频”则带有更明显的技术性特点。所以，游戏音频设计、声音资源、音频数据等这种概念在用词的选择上其实是能体现出各自明显特点的。这种用词上的区别可能只是我个人的纠结，但它们将会贯穿在全文中，所以我想还是有必要在这里澄清一下。

总之我之所以强调自己是“音频设计师”，而非“声音设计师”，是因为我的工作不仅仅是在声音资源制作方面的美学要求，还有更加理性思维的技术实现方面的追求。我不好说，这种将艺术与技术剥离开的分工对游戏音频从业者个体来说到底是好是坏，毕竟这其中还涉及到了个人兴趣选择和术业有专攻的因素。当然，也没有必要因为技术音频可能了解更多技术相关的知识，而觉得这个岗位更加牛逼一些。我只是觉得，这种分工可能会把游戏音频设计变得没那么好玩了。

从实际的工作情境去考虑，使用外包资源来完成声音资源的制作是普遍存在的，在效率和效果上也是有保障的。而如何提出制作需求和进行资源整合等方面的工作则相对来说难以外包化一些，更依赖于一个与项目组内部沟通更为密切、对各方面技术要求更加了解的音频设计师来完成。

所以，这可能也是为什么现在技术音频这一岗位如此热门的原因之一吧。如果你是一位在项目组中只会制作资源的声音设计师，是不是感到了一丝将被淘汰的危机感？如果你是一个满怀创作热情的入行新人，是不是要思考一下自己的技能储备是否完善？

音频程序员负责在游戏引擎中的代码实现。

音频程序员这一角色在游戏开发行业里确实是珍稀动物一般的存在。就目前情况来看，以音频设计师身份入行的人员，大多数都是偏艺术方向的设计与制作出身，缺少了编程能力方面的培训；而以程序员身份入行的人员，在团队编制和架构上其实跟音频组没什么直接关系，如果还能选择来做专职的音频程序员，这样的人真得挺少的。所以，我其实是蛮期待技术音频这一岗位的出现，能让更多的人关注到编程能力对音频设计实现的重要性，让更多的人看到从技术音频转向音频程序员这一条职业发展路径的可能性。