接到侯老师约稿来聊一下参加互动音乐沙龙后有什么感想时，这件事已经大概过去三周半了。 

一般来说，这种观后感需要趁热打铁，才能让语言尽量变得翔实和带有温度。但仔细一想，如果有什么话题让我过了三周依然念念不忘，那起码对我来说，这些话题一定是“真诚且有价值”的；一定是真正能够让我“观后有感”，引起思考的；如果有什么话题在三周后依然可以让我迫不及待的想要将自己或偏颇或不成熟的那些看法与意见，发布在这样范围的一个专业平台上的话，这些话题，可能也就更加配得上大家阅读时渡过的宝贵时间。

倒序

从技术与音乐的讨论权重说开去

对我个人来说，印象最深的，引起最多思考的，是在最后的行业研讨会环节，由8082的李佳骐老师提出的这个议题（这个环节是我个人记忆最深，也是最想先聊到的，所以我回去补看了这段视频）：

首先，李佳骐老师提问说：

“大家是否认同日本作曲家（上田雅美老师）说的，作曲家自己应该了解互动音乐的制作等相关技术？大家的聊天貌似都倾向于一定要掌握。如果是的话，那么声音设计师是不是就不需要参与这类工作了？（这里应该指具体的Wwise设计和引擎实装，如果理解有误请指出）”

紧接着，侯晨钟老师对这个问题进行了回复，大意可以概括成以下这段话：

“我在和周骏辉老师合作时，给自己的定位是Sound Designer与Music Designer（基本上除了作曲以外的工作全部由侯老师负责），但我不认为作曲家一定需要掌握调试曲子在引擎内实际表现的能力，这里最好有一个限度，就是作曲家要知晓常见的互动音乐设计模式，更加“技术”的内容，可以由团队内其他同事代为处理。”

然后，李佳骐老师的回复则反映了目前行业内存在的一种状况，并且非常有启发性，大意如下：

“目前在音频行业内甲方是非常强势的，而甲方在提需求时往往着重于“功能设计”而不是“音乐水准”，导致音乐成品并不好听（一部分源于甲方作为需求提供者，自身的音乐素养并不足），我认为设计师与作曲家应该相互学习，而今天讨论的内容基本都是技术实现方面的东西，我希望听到更多的平衡，艺术创作与技术实现是同等重要的，不要陷入技术的诅咒中去。”

至此，“一个”我个人觉得非常有趣，非常值得拿出来讨论的问题就出现了，之所以这里的一个打上了引号，是因为在我看来，这段对话至少蕴含了以下多个值得仔细讨论的细分问题：

• 究竟如何定义Sound Designer和Music Designer？这两个职能的工作内容和技能侧重分别是什么？

• 作曲家是否需要了解互动音乐的制作技巧？

• • 如果是，为什么？
  • 需要了解到什么程度（侯老师所提到的“边界”在哪里？）
  • 如果不是，为什么？
  • 会对作曲家参与游戏项目的音乐制作带来什么影响？

• 游戏公司提供音乐需求的甲方是否全部较为强势，但普遍存在音乐素养不足，注重功能实现而忽视音乐品质的情况？

• • 甲方真的是永远强势的一方吗？
  • 这里的不足的比较对象是谁？
  • 这里的注重和忽视，分别到了多么失衡的程度？

收束

论游戏音频的生产过程与结果呈现

限于篇幅，我并不会将每一个问题都展开详细讨论，而且，基于我本身有限的工作阅历，看待这些问题时的角度和观点一定也是管中窥豹的。但我之所以还是如此迫切的想要聊聊这些事，正是因为在从一个游戏策划转型为游戏音频后的四五年内，我分别担任过不同公司架构下的Audio Designer/Music Designer/Composer，在不同的岗位，不同的职业生涯阶段内，我基本上遇到过所有上面描述的问题，我也曾站在自己的立场上，思考过这些问题的解法。

所以，今天我想试着以自己的工作经验和角色为原点，以一些网络资料和目前我看到的业内情况做背书，尽量将这些问题收束起来，讨论一个同这些问题全部关联，但可能更加概括的议题：游戏音频的生产过程与结果呈现。

接下来，我会尝试着给这句话下一个定义，通过定义引申出我的立场，再尝试着通过立场，系统性的回答第一章“倒序”内提到的三个大的问题：

我们先聊定义 ：

• 一切玩家无法直接感知的内容，都是生产过程，这些内容包括但不限于： 

• • 甲乙双方制作资源前的需求提供与沟通环节，包括但不限于发现/整合/对接需求，风险管控等内容...
  • Sound/Music Designer需要掌握的所有资源填充和测试的工具与技术，包括但不限于版本管理软件，音频中间件，开发引擎，程序语言等内容... 

综上所述，我理解的生产过程基本上覆盖了除去“资源制作”的所有环节，生产过程顺畅的目的，是保证音频资源以其设计好的，应该呈现的方式，安全的走到玩家面前。

• 一切玩家可以直接感知的内容，都是结果呈现，这些内容包括但不限于： 

• • 音乐质量与音乐播放逻辑；
  • 音效质量与音效播放逻辑；
  • 音频效果设计。

综上所述，我理解的结果呈现基本等同于制作资源的技巧和知识，但有一点需要提出，我认为音效播放逻辑与音乐播放逻辑乃至音频效果处理都属于结果呈现，因为玩家可以在游戏过程中真切的体验到由于播放逻辑和播放效果产生变化而带来的音频体验的实质性改变。

这里引申出我的第一个观点：Wwise（中间件）的使用覆盖了生产过程（资源管理，实装，调试，Debug）与结果呈现（播放逻辑，播放效果）的方方面面，音效设计师与音乐设计师（包括游戏音乐作曲家）最起码需要了解所使用的中间件能实现哪些类型的播放逻辑和效果，因为这直接关联到游戏音频这盘菜呈现给玩家的最终面貌。

我认为，“如何在复杂情况下恰到好处的，有设计感的调用素材”是游戏音频设计师与游戏音乐设计师不可或缺的技能。不掌握这方面的知识，等于忽视了游戏音频设计与传统音频设计的最大区别，也不可能真的理解游戏音频制作中的难点与痛点。而没有了解的直接后果就是没有预判，不玩或者不理解游戏机制，不清楚游戏中真实出现的情况以及处理办法，何谈更好的用自己的制作知识精准的解决游戏内的切实需求呢？

虽然Sound Designer和Music Designer的分工并不是普适的，在目前的国内研发环境下，不同的厂商对音频的解法也并不唯一（其实即使在音频行业较为成熟的国外，不同研发公司音频岗位的设置和职能也一样灵活多变），但无论职位如何，公司内部的音频团队一定要对生产过程和结果呈现负责，这个大前提是不会变的。

至于游戏研发商更加倾向于雇佣哪类人才，恰好，前些天的Wwise官博：Game Audio Job Skills - How to Get Hired as a Game Sound Designer这篇文章，给出了非常有意思的统计数据：100个Game Audio工作JD中，招聘Audio/Sound Designer的比例占到了70%，且对技能需求描述比例最高的分别是：“Experience 69%/Wwise 63%/Scripting 48%/Unreal 41%”...”

抛去任何工作都会要求的“经验”不谈，我们可以很轻易地发现，在游戏公司（甲方）的音频招聘JD中，需求排名前三的技能全部都与“生产过程”密切相关，而与“结果呈现”是否相关，要看具体的职位需求而定（譬如是否不使用Wwise而使用UE4的音频组件来实现播放逻辑？是否招聘程序员进行音频插件的研发等）。

那么，结合我目前的工作经验，引申出我的第二个观点，游戏研发（甲方）招聘音频人才时，在现阶段，无论国内外，生产过程顺畅高效的优先级是大于结果呈现的。这好像是个有点矛盾的悖论，明明玩家最终体验到的是音频的结果，但为什么大家会倾向于招能够确保拥有稳定生产的技能的人才呢？

在我看来，原因主要有以下两点：

• 大型游戏项目的研发过程，就是工业化生产产品的过程，资本需要这个过程尽量可控，所以需要首先保证生产管线的通畅。
• 音效与音乐是相对独立的资源，制作数量与周期同项目研发进度密切相关，且可以外部采买，外部采买在多数情况下也确实更有效率，风格多变，质量更高，符合经济规律。

既然无论国内外，目前的现状就是游戏音频行业一定是由甲方（研发公司）与乙方（偏资源制作）共同协作构建而成的，那么它们一定天然存在分工，而技能加点的侧重不同，必然产生接下来的问题：让注重生产流程的人（甲方）去提同结果呈现密切相关的需求，同时，让不甚了解生产流程的人（乙方）来对接和制作可能涉及到生产流程问题的某些资源，这真的是最优解吗？

聊到这里，我们就大概能明白，李佳骐老师为什么说要“提升音乐素养”与“互相学习”，侯晨钟老师又为什么提出“作曲家了解技术的限度”这个概念了。

其实，行业本身也意识到了这个问题，市场已经给出了答案。虽然国内游戏音频行业成规模成体系的井喷式发展，也就是最近几年的事情。但我们可以看到，一个公司一个项目，只给一个HeadCount用来负责处理和音频有关的所有事务的情况，已经变得越来越少。

现在，市场上很多中大型研发公司开始区分音乐策划/音效策划，招聘自己的TA和音频程序，甚至组建自己的In-house作曲家团队进行项目前期的音乐风格预研，处理同音乐外包团队的需求对接与回包审核，进行部分音乐资源的内部生产；还有的公司会更进一步的包装与宣传作曲团队，用“XX旗下原创音乐团队”作为概念，为产品和公司带来正向附加价值。

这些改变从本质上来说，还是意识到了专业的音频表现对提升游戏品质的重要性，以及“术业有专攻”这个亘古不变的道理。我相信，之后无论甲方还是乙方，大家一定会越来越专业，顺畅的进行协作，最终产出高质量的游戏音频成果。

实现

音频设计师的技能边界

接下来，我依然会延续之前的原则，尝试着在完全不看回放的前提下，回想每一场分享会带给我印象最深的那些时刻，然后总结成一个关键词，足够聚焦，足够诚恳。对于沈希辰&叶梓涛的环节，我印象最深的应该是他们的实现能力，而思考最多的则是当下乃至今后，音频设计师的技能边界问题。

很显然，这两个人都有着足够丰富的知识和足够强大的实现能力，他们所展示的内容除了音乐之外，从设计到Coding全部由两人协作完成（其实他们每个人也拥有独立完成一个小游戏的设计和代码能力），如果说叶梓涛作为Game Designer，拥有一定程度的代码能力并不鲜见的话，沈希辰体现出的设计和代码能力在音频设计师中，还是相对突出的。

如果我之前的分析没有错，这样的人才在研发环境下的优势是十分明显的，因为他不但可以解决已经发生在生产环节中的技术性问题，还可以利用自己的技术视野，从功能设计的角度在更加上游的时候规避和改良游戏音频设计中的缺陷与不足。换句话说，他在团队中的产出更加客观，更加显性，不像资源本身,评判标准较为主观,可替代性相对较强。

这两年，这样的人才明显开始变得越来越多，甚至让一些曾经觉得“代码与音频根本就是八竿子打不着的两件事”的人们，也开始焦虑的啃起了C++，C#和Python，好像这就是音频设计师的未来，不会Coding的Audio只能等着被淘汰一样。曾经的我自己就是这么想的，也在一段时间内试着这么做过。但是随着时间的推移和对行业理解的加深，我的想法逐渐发生了改变。

首先我意识到，总要有人去做资源的，而资源的评判标准虽然相对主观，但“审美”在一定程度上是共通的，能够达到某个“审美”标准的人才，一样非常稀缺。并且，“做资源”并不意味着技术含量相对较低或者相对不太重要。我反倒认为，生产过程的天花板，就是让玩家对生产过程毫无感知。而结果呈现的对象，最终一定还是资源与设计本身。前者的作用是工业的，可被量化的，而后者的上限则更为容易被玩家感性的拔高到某种程度。

其次我认为，并不存在所谓的六边形全部加满的全能战士，即使存在，在固定工时，不燃尽自己的前提下，他也没办法把涉及游戏音频的方方面面全部独立的“同时”做到最好，所以，分工依然是必要的。

最后我发现，知识的维护成本是非常高的，作为一个普通人，当你开坑越多的时候，深入的可能性就越小，如果有些知识并不是你真的在工作中或日常状态下经常调用到的，而是你看到别人拥有所以自己焦虑进而被迫去学习的，失去兴趣和容易遗忘就是你最大的敌人。我认为，在大厂已经开始储备TA（技术音频设计师）和音频程序后，音频设计师的基本盘依然是声音审美与制作能力，游戏阅历，设计思想和中间件使用技巧，而不是代码能力甚至编曲能力，这些都只能算作“加分项”。（当然，这并不妨碍你“想要”成为一个写代码非常好的音效师/作曲家）。

想清楚这些问题，我们再去看这场分享就不难发现，沈希辰和叶梓涛所展示的内容，同他们实际的工作职责紧密相连（游戏策划/TA），他们所维护的知识体系与他们所选定的职业道路有机的结合在一起，我认为这是非常好的个人选择，我也非常欣赏他们两人在分享时展现出的清晰的语言逻辑与自信。我相信无论是他们的职业生涯，还是他们自己创作的Audio Driven的游戏作品，都一定会越来越成熟和精彩的。但我们同时也应该清楚的看到，这不一定需要变成我们自己的选择，这也一定不是游戏音频从业者的唯一选择。

工作流

作曲家的技能拓展深度

关于上田雅美老师的讲座，我想很多人都会对老师分享的整套工作流印象深刻，在仔细的复述整套流程之前，我想先聊下自己当时的一点小惊讶。

我本人算是生化危机，DMC与猎天使魔女系列的粉丝，而且也很喜欢四叶草工作室制作的游戏风格，恰好上田雅美老师都曾以作曲家的身份，不同程度的参与到了这些作品的制作中去。对于一个游戏音乐爱好者来说，我本来是期待着他能多讲一些音乐制作与游戏生产交叉地带的内容的。

然而出乎意料的是，作为一个作曲家出身的游戏音频从业者（如果有更详细的考据，麻烦更正），上田雅美老师讲解的内容基本全都是同“生产流程”有关的知识，譬如Wwise工程的搭建，设计职责的分配，音频行业未来对程序员的需求，以及宏工具。而且老师的观点也很鲜明（细节太多，还是去看了回放，并且不止一遍）：

• Interactive Music并不困难，了解后反倒会觉得非常有趣，甚至可能会节省作曲时间；
• 作曲家最好在游戏研发中占主导（这里的“主导”，我倾向于理解为对交互音乐的结果呈现的掌控力），出于这个原因，他自己负责作曲的项目应该都是自己设计播放逻辑并实装的（老师有提到，其实也并没有人帮他做这件事），甚至外包，他也倾向于把交互音乐的部分全部外包给乙方（前提是自己也需要非常了解交互音乐的设计模式和思路）；
• 系统设计最好以一个人的思路为主导，其他人进行辅助设计（老师建议还是以团队中视野最为开阔，技术最为熟练的人操盘）；
• Wwise与宏工具：老师在提到Wwise时着重讲了使用Wwise要注意避免陷入思维定式，也不要忽略引擎端的音频功能，很多时候如果把Wwise看做“支持工具”，保持其独立性的话，还需要另外的工具辅助才能达到更好的效果，譬如宏工具；
• 音频行业的未来：音频程序的需求会越来越大，因为自动化集成，DSP研发和宏工具，都要靠音频程序来实现。

在对互动音乐和音频设计提出一些框架性的观点后，老师着重讲了自己的作曲工作流，可能对于很多作曲家担心的制作音乐+实装全部由一人完成带来的精力分散的问题有所帮助：

• 集中制作音乐，并在音乐制作中构思交互机制；
• 集中实现，每首曲子的小节与节奏信息都需要导入Wwise，来创造一个随时都可以进行交互音乐设计的工程环境：
  • 老师首先在Cubase/Nuendo内用Arranger Track把想要实现的交互乐段全都划分+测试好效果；
  • 将这些Region导入公司自研的小工具内，快速实装Wwise。在我看来，这个小工具大概做了以下的事情：
    • 建立独立的wwu；
    • 将单次导入的所有乐段放在一个Switch Container下，当做一首曲子进行处理；
    • Cubase内的乐段依据小节信息，按照Music Segment再分组；
    • 自动勾选所有必要的初始选项（Loop/Lookahead/Stream等）。

最后，老师花大量篇幅讲解了他们自研的宏工具（也是我没有完全理解其精髓的地方），在我看来，老师使用宏工具的最主要原因可能是：站在独立音频外包商的角度，经常需要面对不同的研发引擎，面对不同的程序语言与音频功能模块，每次都去学习新的引擎甚至等待一些自研引擎的音频功能逐渐完善才能开始工作是效率低下的，所以需要有一个中间地带来模拟一切游戏内可能产生的情况，面对任何项目都能快速上手工作。

这属于我个人的知识盲区，所以当时我在会议上的提问是：首先宏工具貌似是一种将一切可能影响游戏音频表现的条件进行集成的一个库，然后设计师根据不同的设计内容进行调用，来达到模拟真实游戏环境下音频表现的目的。但这毕竟不是在真实引擎环境下实测的结果，我的个人经验是，在真实环境下可能很多别的因素会影响到音频管线的正常运行，所以我想知道是否会出现在宏内模拟测试并没有问题，但真实测试时出现意想不到的bug的情况出现？

我记得老师当时的回答应该是：暂时没有遇到这样的问题，但当宏工具内的逻辑判断较为复杂时，需要注意引擎处理的速度。

还有一点不确定的是，这里的“不使用引擎而使用宏工具调用Event”的模拟成果，是否可以直接通过提供接口与引擎联调来实现功能？而不仅仅是“模拟”某些音频场景？即形成“Wwise内设计逻辑-宏工具内调用并测试逻辑-引擎通过接口获得宏工具内模拟的游戏条件，并以某种方式直接实装”的工作流？期望有更加理解这次讲座内容的小伙伴，以留言或别的形式进行答疑解惑，非常感谢！

总之，正如我一开始所说，上田雅美老师的讲座涉及到的大部分内容，都同生产流程关系密切，一个作曲家可以把自己的技能边界拓展到这个程度，是非常值得敬佩的。

风铃与爵士乐

非线性音乐的绝佳类比

在回想侯晨钟老师的分享时，“风铃与爵士乐”这个词组非常快速的进入到我的视野，因为平时我自己在思考或者讲述一个问题时，非常喜欢使用类比的办法，所以当时的感觉就是，用这个词组来形容非线性音乐，实在是准确且精妙的，它们几乎具备了非线性音乐的一切特征：

• 本身是可以发出乐音的Instrument；
• 大多数情况下，都有一个既定的大框架，而并不是真正完全随机的无序音乐（预先设计）；
• 需要依靠外力进行发声，并且根据外部条件的不同，音高，音色，节奏都会有所变化（即兴发挥）；
• 观众有机会通过互通影响发声结果（用手触碰风铃=游戏交互条件）。

我相信侯老师是有意识的在选择自己的演讲材料，由浅入深的让不太理解非线性音乐原理的小伙伴，可以从一个较为简单的概念入手，来体会非线性音乐的奥妙的。而他接下来分享的横向与纵向交互音乐设计实例，也是从这个角度出发，来进行一些科普向的知识传递。

让我觉得非常有趣，非常有学习价值的，除了这些类比，还包括最后他与作曲家的整个合作过程。我们可以通过观察他如何将一个音频内容为0的复杂游戏，一步步拆解和转化为各类音频需求，再顺畅的将自己的想法传递给作曲家，并最终在一个相对较短的时间内拿到合适的资源并实装的这个过程，来探讨游戏音频工作者的工作内容，工种划分，操作中可能遇到的问题，以及不同情况下的解法。

首先，体验游戏，理解游戏设计，理解在游戏设计背后想要传递的玩家体验并最终转化为贴切的音频需求。

• 技能点：游戏阅历，逻辑思考能力，文档能力
• 对应职能：音频策划/音效设计/音乐设计

其次，将体验转化为音频技术选型（横向/纵向/融合），并同作曲家讨论交互音乐选型。

• 技能点：音乐素养，设计能力,中间件使用能力，沟通能力
• 对应职能：音频策划/音效设计/音乐设计

再次，同作曲家商讨并明确曲风，给予作曲家充分的信任，相信作曲家有更多的“风铃”，能更精准的处理音乐需求。

• 技能点：音乐素养，沟通能力；如果自行制作音乐，则需要音乐制作与混音能力
• 对应职能：音频策划/音效设计/音乐设计/作曲/编曲/混音

最后，实际制作中，让设计贴合体验，同作曲家交流实装需要的资源形式，进行实装及测试。保证资源按时，安全的进入迭代。

• 技能点：中间件使用能力，引擎使用能力，代码能力，QA职能，PM职能
• 对应职能：音频策划/音效设计/音乐设计/QA/PM

经过上文内浅显的分析，我们不难看出：在具体研发流程中，音频部门需要覆盖多少细分职能（以上例子还未包含语音与资源外包等大体量的内容）。当项目足够复杂时，一个人是不可能，也完全没必要同时处理如此繁杂且需要不同技能侧重的工作的。站在企业的角度，将所有管线全部交由一人打理也并不科学。所以我认为，作为从业者，我们一定要找好自己的方向，知道自己的兴趣点与长处在哪里，切忌盲目焦虑或跟风努力。

其次我们应该注意，在制作这样一个复杂的音乐设计时，如果作曲家并不懂Wwise，甚至不清楚常见的交互音乐制作方式和特征，那么沟通成本会变得多么高昂。更别提在日常工作中，我们很多时候要同其他国家的作曲家进行对接。地域文化差异，时差和语言习惯已经为沟通平添了很多壁垒，如果再加上需要阐述技术实现这个环节，我们对结果的把控会变得更加具有风险。这也是我个人为什么倾向于选择同制作过游戏项目，了解互动音乐实现模式的音乐人合作的主要原因。

最后，在分享中侯老师曾提到，其实作曲家每天都在DAW里做类似的事情，只不过自己没有意识到罢了。我深以为然。我的个人感觉是，比起音乐中那些复杂的和声与对位，节奏与声响，花点功夫理解常见的游戏音乐设计模式实在是件异常简单的事情。我相信一个真正想要做好游戏项目的作曲家，只需要花些许时间，就一定能理解游戏音频中常见的设计思路；只需要玩一下自己参与的游戏项目，就一定能拥有更多更贴合的音乐灵感。

所以我的观点是：作为一名游戏音乐作曲家，只有我们真的去正视和了解游戏音乐与线性音乐的不同，才能在为其进行创作时，发挥自己的全部潜力。

结语

社区与分享是行业进步的基石

非常感谢Wwise和侯老师可以给我一次分享的机会，让我能够借这个平台，借着参与互动音乐沙龙后进行的一些思考，来阐述自己对游戏音频行业的理解与展望。从我个人的职业生涯来看，我所获取的知识与技能很大一部分来自于各类专业频道与论坛，来自于整个音频Community无私的馈赠。我特别希望这样的活动能够有规律的，持续性的举办，能够把一群优秀的人聚集起来，从不同角度，探讨同游戏音频有关的方方面面。

希望大家都能参与到Wwise提供的这个社区中来，不断提高，持续进步。

互动沙龙回顾视频，请点击此处。