游戏音频技术备忘 关于游戏开发

Posted 2020-08-29

　　千里之行始于足下，一款游戏如何从无到有？诗人构思许久后动笔写作，音乐家在乐谱与乐器间来回修改，画家调节颜料比例涂抹在画布上，文学音乐绘画都要经历如上所述大致相同的创作流程。游戏不同与往，游戏杂糅了几乎所有艺术形式的特征，一方面我们还要进行传统的 文学音乐绘画创作，另一方面我们要额外考虑如何把这些各自分隔的内容糅合在一起，并且提供一套交互系统用以产生变化，这时候我们就需要一个工程师来实现这一目标。

 

　　作为电子游戏，建构虚拟世界的根基是各类的计算机硬件，我们需要一块屏幕用以显示图像，一只喇叭用以播放声音，一块处理器用以计算各类变化，一块存储器用以存储各类数据，以及一套用于输入指令的设备。当下用于游戏的计算机硬件大致有三类，最常见的就是个人电脑，上述所有硬件需求已经囊括在了一套完整的个人计算机系统里，因此我们不再需要额外的硬件，只需拥有游戏的数据就能开始游玩；其次是专为游戏设计的计算机系统，我们称运行在这样的系统上的游戏为Console Game，也即我们俗称的主机游戏，这样的硬件系统往往不提供屏幕与喇叭，只提供最核心的处理存储系统与输入设备，一部分便携式的主机则把所有硬件都设计组装在一起；最后是这十年数量与技术增长迅猛的移动电话，随着处理器性能与屏幕技术的发展，在手机上也出现了越来越多的电子游戏，囿于当代社会快节奏的生活方式，以及较为容易获得游戏的原因，手机游戏在当下拥有更广泛的受众。然而一切都处在变化之中，人们对游戏的需求也不是一成不变，因此用于游戏的硬件设备也时常更新换代，不过游戏根本上所需要的硬件，在提供图像声音的反馈、数据的存储与计算、以及输入指令这些方面还未产生变化。

 

 

　　在拥有了硬件之后，我们在开始正式创作游戏之前首先需要让各自独立的硬件拥有互相通信的能力，否则我们难以实现游戏在多个维度与人交互的愿景，好在当下已经有了非常成熟与工业化的工具来达成这一目标。

 

　　首先在图像领域，当今绝大多数游戏的图像部分都由一块专用芯片来进行计算，即GPU图像处理器，由于在二维屏幕上绘制变化的图像所涉及的数学运算多在线性代数范畴内，加之计算机芯片技术的特性，因此经年累月已经形成了由 专用芯片负责图像计算的情况，尤其对于3D游戏，需要在很短的时间内大量绘制多面体并着色最终输出到2D的屏幕上，其中非常多的矩阵运算、坐标系变换、光照与物体表面的纹理渲染、物理现象模拟都需要在几十分之一秒内完成，而计算机图形学也顺理成章地成为了程序员的三大浪漫之一（另外两个是操作系统与编译原理？），毕竟浪漫之物必然难以追寻，如何准确高效地在屏幕上显示出精妙绝伦的画面已成为了衡量一款游戏优秀与否的一大标准。

 

　　由于计算机处理器的工作原理相对于人的思维来说非常难以切身体会， 处理器设计者为了效能与效果最大化了芯片的抽象特性，因此为了显示图像直接与GPU交互显然是一件费力不讨好的事（实际上GPU作为一个计算器也无法直接交互，总是要通过CPU来下达计算任务），因此人们采用了一种思路，把芯片的若干操作用某种单一指令“封装”起来，好比我们对朋友说一句“一起去吃饭”，朋友（答应你的情况下）就会“自动”地“起床”-“穿衣洗漱”-“出门”而不必你依次发出各阶段指令，尤其是你的这位朋友是一个赖床爱好者的情况下，大部分你与她的交互都要先下达“起床”指令，这时候把若干操作封装起来就显得再经济不过了，一方面避免了与处理器的直接交互，另一方面使得指令具备了一定可读性。这种在问题出现时添加一个“层”的做法在工程开发领域屡试不爽，当然层的数量也不是越多越好，如何在层和抽象之间取得平衡点，也是广大工程师的一大难题，一般称从事这种结构设计的人为架构师，如同建筑工程师，软件硬件的架构直接关系到性能效果稳定性鲁棒性与易用性等方面。

 

　　现今游戏研发所使用的易于控制的图形“指令”大都封装在高级语言层面，这些指令我们使用接口（Interface）这一名词来命名，我们无需了解硬件在接收到某一接口消息后发生了什么，我们只需关注该接口能否实现我们所需要的效果，这也是所谓接口与实现分离原则 （实际上对于图形编程常见的Cg/HLSL/GLSL等语言，由于不具备C/C++/Java/Python等语言所具有的条件逻辑语法也不被认为具有图灵完备性，另话不表） 。PC平台最常见的图形编程接口集为Direct Graphics和OpenGL(实际上他们也并未与硬件直接交互，这些接口集都是通过C/C++这样的高级语言实现的，在其之下还有系统与驱动才能触及硬件，实际情况中游戏分层复杂，后话)，有了这样的API集软件工程师就可以较为轻松地开展工作了，大部分基础的图形相关接口都已实现，剩下的就是如何组合这些接口供给游戏使用。不过其他平台就没有这么好运了（实际上只是没有Direct Graphics而已），在移动平台OpenGL有一个OpenGLES子集，当前还出现了Vulkan这样强大的新一代图形API标准。

 

　　同样的，在音频领域也有一些可使用的API集，例如DirectSound/DirectMusic、OpenAL、XAudio等，由于计算机音频技术相对图形技术已经很早就实现了硬件能力远大于计算存储需求（当下由VR技术带起的一波沉浸式音频渲染又一次开始挑战硬件），加之游戏内的音频相对图像，大部分情况下就是现实世界的重现而不是实时生成， 因此相对地多年来相关技术的进步也比较稳当且不是很引人注目。不过随着虚拟现实概念的出现，音频相关技术又一次走到了风口浪尖，近年来物理建模声学领域也有很多新成果，总体上音频技术也有非常多值得深入的细分领域。

 

　　对于游戏的计算存储，这一方面与其他绝大多数软件开发无异，我们需要构建不同的程序执行逻辑（初始化、异常处理、交互事件、网络模型等等），需要构建数据的管理器（内存分配与回收、数据的读写与封装等等），在实际开发中还要考虑多人团队的工作方式（各类图像音频资产管理、版本控制等等），大部分游戏程序员所从事的工作都在以上几个方面。

 

　　而输入指令这一领域，大部分情况下算是游戏开发中比较简单的一个范畴，无论是鼠标键盘，手柄还是手机本身， 绝大多数游戏运行的硬件平台已提供控制器。当然随着各类设备和概念的出现，有时候设计一个输入设备反倒成了最难以实现的事。同样地，DirectInput API集（ 所有的微软Direct API集的总合被称之为DirectX ）提供了一些在Windows平台上可用的游戏输入设备接口。广义来看现今具有身体/头部追踪的HTC Vive/Oculus Rift，包括早年的Wii主机，都拥有在拟真方向上具有很高可玩性的控制器。

 

　　大体上我们拥有了这些的工具后就可以开始开发游戏了（当然还需要能够进行编程编译、数字化图像音频的工具），话说起来虽然容易，游戏开发任何一个阶段，任何一个方向上都有太多值得探讨的内容，泛泛而谈往往显得空洞，不过准备足够的理论知识总是可以更好地应对问题。

 

　　当然随着游戏开发的历史变迁，人们越发发现有很多方面可以像CPU指令集和图形/音频编程接口一样进行抽象封装组合，这样大量基础的功能就不再需要反复实现。随着这种在游戏开发过程中积累工具集合与软件模块集合到一起的模式日益成熟，我们开始使用一个新的名称来称呼这种集开发工具与游戏底层模块于一身的软件集，这就是游戏引擎。实际上，当前游戏研发使用已有游戏引擎的情况非常常见，一方面复杂的技术限制了从零开始的可能，另一方面对于快速迭代的市场需求，作为一种商品，游戏本身已很难适应缓慢的研发周期，因此使用游戏引擎开发游戏，某种程度上也能减少很多成本，正如我们买了发动机，只需要再买车壳和轮胎等组件就能制作一台车一样（实际上应该没人这么做……）。当然对于任何超过某种游戏引擎提供的功能的需求，我们还是要回到最基础的部分进行开发，幸而由于分工细化，大部分游戏引擎的开发人员都是专职的。而由这种定制化的需求，又催生了各种中间件与插件，可以作为灵活加入的模块接入到游戏中去，我们在很多游戏的第二屏技术授权展示页看到的各种Logo，大部分都属于这样第三方技术，全局照明距离剪裁植被生成物理模拟3D声音等等等等各方各面都有不少可供选择的技术。