大家好，我是溪夜。
游戏技术音频领域一直是我非常感兴趣的方向，这也是在书单《游戏音频与声音设计相关书籍推荐》文中专门列出技术音频相关书目的原因。
近日有感于希辰老师的《游戏音频设计师、技术音频设计师和音频程序员》一文，想谈谈我认为的“游戏技术音频”相关定义和技能路线。
这篇文章包含我最近一年多对技术音频职业的思考，及已经掌握和正准备学习的技能。希望能在国内这个相对较新的职业领域中分享一份我自己的总结，如有遗漏欢迎指出，期待与大家共同交流。
附《游戏音频设计师、技术音频设计师和音频程序员》阅读地址：https://zhuanlan.zhihu.com/p/295783076
第二版更新内容：
- 改进文字表述方面的细节。
- 增减了部分内容。
本文目录：
[toc]
职业定义的思索
1.1. Technical Audio Designer 或 Technical Sound Designer（技术音频设计师）
这两者都可指代技术音频设计师，第一次见到 Technical Audio Designer 的说法是在育碧的 JD 中，而见到 Technical Sound Designer 则是在 Damian Kastbauer 老师的书名中。
在这里默认两者都指代技术音频设计师，不讨论是否存在谁偏向资源制作，谁偏向音频播放规则设计的话题。
我想反思的是技术音频的“职责“，把职业方向定位为技术音频设计师不应是对其他工种的逃避或看这职业缺人就急着扎进来，而应该是因为有着对掌握更全面的游戏音频技能的追求。希辰老师在文章中就曾说到“这种分工可能会把游戏音频设计变得没那么好玩了”，这点我深以为然。
因为对技术有更深入的追求，不是仅仅做资源了事，而是想把制作、整合、Debug、效率提升的整套流程全部跑通，所以才自然而然的走到了游戏技术音频领域，私以为这才是一个比较正常的职业发展路线。
1.2. Game Audio Programmer（音频程序员）
普遍意义上的 Audio Programmer 会更偏向底层一些，工作中会涵盖 DSP、音频算法、效果器和虚拟乐器的实现等知识。这也是为什么我用 Game Audio Programmer 而不是 Audio Programmer 称呼的原因，对于游戏音频程序员来说，这样描述更加准确。
个人认为 Game Audio Programmer 与 Technical Sound Designer 的工作界限可能更为接近于“渐变”的关系，即 Technical Sound Designer 应该是 Game Audio Programmer 的过度。停留在开发小工具和做声音设计师与程序之间的润滑油可以是一个中间态，不停止对更完善的技术进行探索才是有趣的前进方向。
游戏引擎及中间件技能
2.1. 游戏引擎
2.1.1. 引擎使用
常见商业引擎的使用绝对是最基础的要求，除非自我定位为只做资源的“音效资源机器“，否则至少根据项目要求 Unity 与 Unreal Engine 其一需要掌握完整的使用方法。此外并非了解简单的操作就完了，而应该找个小游戏项目从制作、整合、打包完全跑一遍。
在此之外闲暇之余看看 CryEngine、Godot 乃至 Armory、Defold、GameMaker 等引擎中的音频实现无疑也是有趣的事，不过还是以项目为主，着重在当前项目所使用的的目标中发力，这也是音频集成的基础。
2.1.2. 无中间件的音频集成
这里谈到的音频实现是指用引擎本身的音频功能完成游戏声音整合，虽然不少项目都上了音频中间件，但我认为传统手艺不能丢，万一赶上简单的项目需要全盘用引擎本身的音频功能实现岂不抓瞎？
本人的音频进阶计划中就包括如何用各大引擎自带的音频功能，去复刻中间件可复刻的一些实现以此加强对引擎本身音频整合的了解。
2.1.3. 热更新
对于手游项目，热更新是离不开的问题。如何根据项目现有热更新框架，实现音频资源和代码的热更新是必须了解的。
这也是技术音频设计师全局观的体现，提交完当前的版本后还需考虑后续的小版本更新与大版本迭代如何搞定，并在过程中 Debug 以保证正常的版本交接。
2.2. 音频中间件
2.2.1. 中间件使用
三大商业音频中间件 Wwise、FMOD、CRIWARE ADX2 一定要根据项目所需学透，把文档整体过一遍更是必须完成的工作。
泛读并非为了显摆自己的学习能力，而是通过泛读并整理后知道一些“不知道自己不知道”的知识，从而扩大自己的“知识视野”，以便于在工作中出现疑惑时脑子里蹦出一个关键词提醒自己这个问题还可以这么解决。
在使用 Wwise 的时候我就发现太多问题是因为自己没通读文档、官方 Blog、没勤翻问答区的常见问题等，这些都是提升中间件掌握的好途径。
除此之外，Fabric 作为一个相对以上三者来说，授权费更便宜一些的音频中间件，也可以作为“茶余饭后”去了解一下的中间件甜点。
2.2.2. 音频整合与优化
整合音频无疑是最重要的，中间件提供的集成包本身会提供方便的音频部署机制。
但自定义脚本乃至调用底层 SDK 仍然是要掌握的部分，了解集成包底层的调用规则对理解中间件工作原理与 Debug 无疑很有帮助。从这点来说，看一下集成包的实现代码也是有必要的。
此外，如果想要作出更为复杂的音频效果，尤其是音频或音乐驱动的游戏。对音频 SDK 有深入的认知也是必要的，总有些工作需要直接对着底层发力。
2.2.3. 语音对白
对于游戏中人物对白来说，在大型项目中需要通过 TTS 产生语音临时文件进行占位，也需清楚地记录录制情况，自动化后期处理和批量集成时的繁琐工作。
掌握当前技术方案下的 Lip Sync 实现也是一个重要的方向（如果角色有嘴且能动的话）。
效率优化技能
3.1. 游戏引擎脚本工具开发
3.1.1. Unity Editor Scripting
在 Unity 中开发自己的工具需要使用 Editor Scripting，需要在 UnityEditor 命名空间上做文章，实现的工具也是以脚本形式存在的。
无论是简单的 Unity 中实现中间件的播放功能预览，或是创建一个独立的音频 Profiler，这些都需要了解如何在 Unity Editor 中创建自定义脚本并为其加上 GUI 以方便用户使用。
3.1.2. Unreal Engine Editor Scripting
与 Unity 只能用 C# 开发工具不同，Unreal Engine 除了可使用本家的 C++，还可以使用蓝图或 Python 来创建脚本工具。
对于 C++ 水平尚且一般的我来说，支持其他两种开发方式在跨引擎迁移想法时会减少很多阻力。
3.2. 中间件效率开发
3.2.1. WAAPI (Wwise Authoring API)
WAAPI 作为 Wwise 重要的进阶功能，它允许用户通过代码快速完成 Wwise 中大多数鼠标键盘才能完成的重复工作，为大家提供了多样的工作流定制的可能性。
在我的系列文章《人人都能用 WAAPI》中对 WAAPI 的重要与使用方法进行了讲解，对于技术音频设计师来说，就是要通过 WAAPI 把中间件跟其他音频工作分离的工作尽量整合并提高效率。
帮助大家快速对项目所需的工作流完成工具定制，这也是 WAAPI 系列文章的写作目的。
3.2.2. FMOD Scripting
FMOD 中也有效率提高相关的脚本支持，但与 FMOD API 进行整合时可用的四种编程语言不同，FMOD Scripting 只能使用 JavaScript 驱动。
对标 WAAPI 的分类，FMOD 的脚本 API 也对应着从全局到细节的各个部分，对于各种效率优化想法都能提供很好的支持可能性。
3.3. DAW 效率开发
3.3.1. REAPER + ReaScript
作为性价比、可扩展性、工作效率都超强的现代宿主，REAPER 在游戏音频行业中现在用户群体愈发壮大。本着一切均可优化的原则，ReaScript 作为 REAPER 的脚本语言支持自然也需要被拿出来提高工作效率。
在我的系列文章《补完 REAPER 效率链的最后一环》中，详细的介绍了 ReaScript 的来龙去脉，以及 Python 程序员想要以更 Pythonic 的方式调用 ReaScript，欢迎大家参考。
3.3.2. Cubase / Nuendo + Logical Editor
虽然 Cubase 没有脚本语言支持，但 Logical Editor 也能提供一部分自动化的解决方案。
局部的 Logical Editor 可以对 MIDI 进行操作，如一键完成设定好规则的 MIDI 音符操作。全局的 Project Logical Editor也可对工程级别进行操作，如一键隐藏所有 MIDI Track 只保留 Audio Track。
与 ReaScript 能提供的全范围 API 相比，Logical Editor 更多的是对使用 Cubase / Nuendo 的声音设计师自己的工作流进行优化。所以在进行工具链开发时，Logical Editor 相对而言是无法被集成进去的。
3.4. 通用工具开发（GUI 开发）
3.4.1. Python
众所周知 Python 是一门易学难精的语言，但也的确是初学者上手速度最快的编程语言之一。对于技术音频设计师来说，快速敏捷的开发出项目所需工具且，并附带同事看得懂的 GUI 界面，无疑是一门基本的技能。
入门相对友好的 Python GUI 框架中，除了在我的系列文章《写给声音设计师的极速 GUI 开发大法》中提到的 GUI 框架封装 PySimpleGUI 外，还有 DearPyGui，但其相对简陋。
当然，如果你想要 UI 设计更符合现代设计美学，并想开发一些自定义控件，那还是用 PyQt 好些。除此之外坚守原生的 tkinter 或其他库比如 wxPython 等也是较好的选择。
但说实话，Python 的 GUI 开发时语法优美程序远远逊于 Python 本身的语法，这也是为什么我更推崇 PySimpleGUI 的原因。正如这个框架介绍中第一句话所写：Python GUI For Humans.
3.4.2. Electron
在与胡磊（Moy）老师的聊天中我们聊到了 Electron，作为一个桌面应用程序框架，Electron 可以使用 JavaScript、HTML 和 CSS 来构建 GUI。其语言结构本身就决定了 Electron 在跨平台方面能顾做得很好，而且代码布局结构比较清晰。
相对而言，制作整合多个程序且跨平台的大型工具项目，Electron 比 Python 或许更为适合一些。但作为 Python 的拥护者，我目前对这种看法持保留意见。
3.4.3. MFC, WPF and more…
无论是 Windows 上的 MFC、WPF 或是 macOS 的 Cocoa，我认为做小工具开发都颇为笨重，无法跨平台也是一项大的缺陷。鉴于本人对这部分 GUI 框架认知较为浅薄，在这里不妄加评论。
3.5. 日常工作流改进
所谓“日常工作流改进”，可以理解为是技术音频设计师自己工作流的改进，也可以作为工作流优化布道师对团队内其他成员的效率进行优化。
思考技术音频设计师的工作职责，狭隘的局限于开发工具一定是不够的。对于音频工作的方方面面都应该有着优化的见解，这样才能够从各个角度改进团队的工作效率。
而日常工作中，正是会出现各种各样的低效率重复行为。这些非代码的优化工作，也同样是技术音频设计师的重要职责。
3.5.1. StreamDeck
StreamDeck
其实 StreamDeck 在音频与直播圈子里也算是比较广为人知了，它的主要工作逻辑就是重定义你的工作流，把一切你需要的功能都做到“一键即达”。
简单来说，可以一键搞定快捷键，打开程序，打开网页。复杂一些的话，可以用 StreamDeck 触发 Python 或其他脚本以实现更复杂的功能。
3.5.2. Metagrid + Keyboard Maestro
Metagrid
Metagrid 是一款 iOS 上的类似 StreamDeck 的 App，但相比 StreamDeck 而言，Metagrid 的功能更为自由且开放，得益于 iPad 大屏幕的支持，可以实现更复杂的功能直通车按键。它可以对每一个应用程序有一套单独的控制页面，新增的 Omni Space 更可随时切换到全局模式以对系统全局进行操作。
对于我等 macOS 用户来说，与 Mac 专属软件 Keyboard Maestro 的深度整合，更可让 Metagrid 用户不需要发送 MIDI 信号即可轻易控制 Keyboard Maestro 中的诸多复杂功能（Keyboard Maestro 简单来说就是把 REAPER 的 Action List 功能搬到了 macOS 全局，是一个极其强大的软件，更可与 Apple Script 等联动）。
在使用过程中我与开发者 Przemek 有过不少的邮件往来，对 Metagrid 有着深厚的感情。如果你有 iPad 的话，建议买一个试试看，会获得比 StreamDeck 更为优秀的效率提升体验。
新版的 Metagrid 还支持从 DAW 中读取时间码，对 DAW 的走带控制愈发完善。论坛中还可看到大家分享的诸多控制模板，可以拿来即用。并且在交互上进行了大刀阔斧的改良，现在的手势操作逻辑非常方便。
3.5.3. TouchOSC 与 MIDI Designer
TouchOSC
MIDI Designer
与前两者相对固定的按键排布方式不同，TouchOSC 和 MIDI Designer 均可按照自己的想象随意绘制控制器控件及布局，这对于控制 DAW 或合成器进行工作时无疑是及其高效的。
其中 TouchOSC 支持 OSC 协议，所以实际上还可以玩很多 MIDI 协议做不到的事情，鉴于这篇主讲音频设计工作流提升，在这里就不展开谈 OSC 的强大了。
3.5.4. Auto HotKey
Auto HotKey 是一门 Windows 下专属的热键脚本语言，之所以放它上来，是因为 Metagrid 在 Windows 下没有 Keyboard Maestro 的加持有些工作会不太方便。
因为 Metagrid 支持通过 MIDI 信息触发指令，所以可以用 Auto HotKey 的很多用户分享的扩展库实现 MIDI IN 的获取，以此让 Metagrid 触发脚本从而实现更为复杂的功能。
项目管理技能
4.1. 工程架构创建
为新工程创建架构，构建命名规则等宏观的工作，会从要求技术音频设计师有全局观的设计能力。在我看来，这还应该有对可能出现的坑和技术栈需求有一定的预判能力，才是一个完整的大局观的体现。
4.2. 技术文档与 Wiki 写作
4.2.1. 思维导图
思维导图的好处不必多说，进行自我或团队的头脑风暴都很有用。
在执行工程规划和技术路线安排时候，也可轻松的展示出分支的变化。
4.2.2. 印象笔记、OneNote、有道云笔记、为知笔记及 Notion 等
现代的笔记类软件多有团队协作类功能，其中国人开发的 Notion 近些年尤为火热。
个人端使用这些软件可能更多的是做 PKM 和 PIM（个人知识管理和个人信息管理），团队的应用场景下更多的是为了项目交流及团队内训。
所以在这部分上，也要有足够的认知以便于随时提供团队级的技术解决方案。
4.2.3. 技术 Wiki
书写工具使用文档和公司内部技术 Wiki 也是一个必备的能力，对于公司内部的技术传承无疑是很重要的，这就要考验大家遣词造句的功底了。
文笔稍差不可怕，但中英文混排、标点符号使用、代码注释等基本规则一定要谨慎。不在意这些小细节，文章写得再好读起来体验也是一坨屎。
如果要对外不公开，可以折腾 MoinMoin Wiki、DokuWiki 这种框架。
如果不在意公开，个人观点是把技术 Wiki 放在 GitBook 上也是很好的体验（当然，一般来说内部技术 Wiki 都没法公开）。
4.3. 版本管理
版本管理是编程中必须掌握的工具，而对于中间件工程而言，使用 Perforce、Subversion、Git 进行版本控制也是开发中必须要进行的流程。
为了降低版本控制时每次传递的文件大小，需要选择性的对工程中不重要的文件进行忽略。
编程技能
如果说技术音频或音频程序员需要会编程，为什么听起来和代码毫无关系的声音设计师也要学习编程？
对于这个问题，可以从两点解释：
第一，学编程不是为了成为“一体机”，而是为了解决自己的工作中可能出现的能用编程解决的问题。没错，随着工作的细化或许公司会配备专职的“技术音频”来完成工具开发的工作，但当技术音频没法帮忙的时候该怎么办？或当在做公司之外的工作时，还要去求“技术音频大佬”帮写小程序吗？
如希辰老师所说，这些本质上就是游戏音频设计师分内的工作，虽然工作细化会导致各种职责愈发清晰，但这不是成为资源内包人员的借口。
拥抱变化是所有优秀人才必备的能力（不仅是程序员），守住自己一亩三分地而沾沾自喜的，那是死人才会有的想法。
第二，相信有些人听过 Learning Curve（学习曲线）的概念，学习曲线一般都基于两种模式。
其一是对数曲线，在初期学习速度与收益飞快，并逐渐进入平台期，多见于入门简单技能的学习。其二是指数曲线，初期无论是学习速度还是收益都很差，但复利效应强大，后期会获得爆发性的突破。多见于各种产生睡后收入的场景，如写文章、教程、创作文艺作品等。
而对于为了解决重复而进行脚本编程，常用的语言绝大多数都属于学习曲线是对数的情况（编程语言有个规则即诞生的越晚，一般就更易学更人性化。如 Python（1991）、Lua（1993）、C#（2000）相对 C++（1983）来说分别对应了第一种和第二种学习曲线）。
对数形态的学习曲线导致它们的学习体验在初期会让人很快的感受到收益与反馈，所以可以用很短时间就接触到不少其它领域。而这部分技能往往已经足够你应对一些常见的工作。毕竟如果目标是成为一个 C++ 算法工程师，指数形的学习曲线会让初学者望而却步，但很明显这不是大多数人需要的方向。
5.1. Python
Python 对技术音频的工作而言，可以拿来写本文上面提到的诸多脚本，以及能够开发 GUI 工具。无需多说，属于必备且必学的语言之一。
但就像上面提到的，入门容易精通难。学习 Python 不能被友好的语法和高容错率蒙蔽了双眼，对数据结构、算法乃至设计模式等 CS 基础知识也要补上。
5.2. C# 与 C++
C# 与 C++ 除了分别对应 Unity 和 Unreal Engine 的御用语言之外，C# 在 WPF 开发也有很大用处，C 或 C++ 在实现底层的东西或开发插件时也是必备的。
虽然小题目中没有列出 C 语言，但它对学习了解 CS 基础知识非常合适。在初中时期看过的谭浩强的《C 程序设计》令我反胃，但确实在很早的时候就为我对计算机原理的了解打下一些基础，不至于在成年后编码时产生过多陌生感。
5.4. Lua
Lua 的主要用途有两个，一是作为热更新框架所采用的语言，二是可用在 ReaScript 脚本及工具开发上。
因为 Lua 和 Python 类似也是很好入门的脚本语言，参考 Python 对比学习语法是再好不过的了。
5.5. JavaScript
JavaScript 的主要用途在本文中也有体现，比如作为 FMOD 的脚本调用语言，或者作为 Electron 框架的开发语言来开发跨平台桌面程序。
5.6. 了解 SDK
了解 SDK 这个说法比较宽泛。就我个人的观点，这代表了技术音频设计师至少要了解这些有 SDK 字样的文档的阅读和使用方法：比如游戏引擎中音频 SDK、中间件的底层 SDK 使用以及在集成包上如何实现的、引用命名空间时清楚不同模块的用途等。
费力完成这些最终的目的倒不是为了全部徒手用 SDK 撸完集成，而是有更完善的工作原理理解和 Debug 能力。
5.7. 编码规范 todo
其它必备技能
有一些技能相对技术音频工程师的职责而言比较杂乱，故单开一个章节归纳到一起，以方便读者阅读。
6.1. 音乐基础、电脑音乐制作、录音、混音及声音设计等
有一定的音乐基础，掌握常见的电脑音乐制作及后期处理工作流程，同时还有一定的声音设计能力（如合成器编程、拟音录制、效果器使用）无疑是技术音频设计师本身职责之外的必备基础。
这些知识一方面决定为什么技术音频设计师属于音频设计师而不是纯程序员，另一方面也决定了技术音频设计师在掌握交叉技能的同时保留了足够的审美能力。
保留审美能力对于一个在艺术类团队中的技术工作者而言，这决定了工作的下限，让你不会为了技术而完全抛弃对审美的追求。
6.2. 音频技术
在与游戏业内朋友交流时，我发现并不是所有人都对音频技术了如指掌。比如对于音频工作者而言，如何在公司现有的条件下打造更好的监听环境，如何在出租房内为自己打造能够工作的监听环境，市面常见的声学装修或声学矫正方案的优劣对比，音频设备的品牌、优劣、如何选择等。
这些对于传统音频行业从业人员来说相对比较容易熟知的内容，我被游戏行业内的一些朋友咨询过很多次。
虽然也可归纳为信息检索与解决问题或音频基础知识的匮乏，但我还是认为一个技术音频设计师也应该在传统音频领域有所建树，对于录音棚装修设计、音频设备解决方案设计、软件设计等方面也应该有着比较全面的见解。
对音频行业具有比较全貌的了解的话，提升起团队的工作效率也更加得心应手。
6.3. DSP
对数字信号处理（DSP, Digital Signal Processing）有一定认识的话，至少能够遇到相关知识不打怵。作为跟代码、效果器打交道的游戏音频从业人士，连奈奎斯特定理、傅里叶变换等基础知识都不知道，着实有些说不过去。
而如果具有一定的技术基础，能够用编程语言复现一些信号处理算法（FFT、DWT），或者根据 DAFX 这类书籍开发效果器（如使用 JUCE 框架），在项目中需要开发效果器时无疑会有很大的帮助。
6.4. 英文
英文能力的重要性体现在诸多方面，这里先不讨论是否要对国外接外包或去国外工作，单单日常的工作和学习来说，英文就已是离不开的能力。
太多的教程和书籍都是英文原版的，第一手新闻和行业资料（没事可多翻翻 Twitter）也全是英文，中间件，程序代码更是如此。
在这个问题上，我跟声音设计师要不要学写代码的地方持一样的看法。与其等待本地化，不如主动出击学好英文。
6.5. 信息检索与解决问题
信息检索和解决问题的能力应该是现代人立足职场之本。
我几乎所有的研究与写作都是靠自己完成的，致谢中虽然提到了一些同行老师的名字，但我所获取的更多只是一些“关键词”。
举个例子，在去年了解有技术音频这个职业名称后，不仅顺藤摸瓜找到了诸如 Guy Somberg、Damian Kastbauer 等老师的书及演讲视频等资料，更是靠自己检索出了整套《游戏音频与声音设计相关书籍推荐》书单（除少数几本是朋友推荐）。
而对于解决问题的能力，除了要有极强的文档（RTFM）和 Google 检索能力外，更应该学会如何正确的提问（可参考 How To Ask Questions The Smart Way）。在掌握了解决问题的诸多技巧后，我所遇到的提问题的场景变得越来越少。相反，在自我提问并自我解答的这个过程中，反而收获了越发广阔的视野。
我想这也是元认知、复利、独立思考等思维技巧带来的综合结果，它们使人愈思考愈智慧，而不是成为一个简单的伸手党。
One More Thing
创办亥姆霍兹实验室这个公众号的动机非常简单，就是为了分享自己的一些研究和思考。不敢自吹自擂说能推动行业进步，但至少挂了之后能给世界留下一点点有用的文字。
我的短期计划（两三年内）有一部分，就是希望把本文中提到但目前没有特别好的文章去讲解的部分技能写成文章与大家分享。与此同时，随着我对技术音频设计师理解的更加深刻，这份清单的技能树也还会继续完善。
致谢
在这篇文章中包含了直接或间接从同行老师的言谈、文章、朋友圈等地方学到的知识，在这里列出诸位的名字，感谢他们的鼓励与分享！
以下排名不分先后（以拼音顺序）：
侯晨钟，胡磊（Moy），李AA，沈希辰，岳豪，杨磊，zpan