《硬核机甲》（Hardcore Mecha）的音频设计 - Part1

Chengsoul

《硬核机甲》是一款以精致动画演出和高速战斗为特色的、着重于驾驶机甲的厚重感和真实感，将格斗射击平均混合机甲题材横版动作游戏，现已在PS4与Steam平台发售，赢得了Fami通33分、IGN日本8.8分的好成绩。游戏有剧情战役和多人对战两种模式，战役模式总计8章节18关，包含了矿坑、水下、市街、宇宙等多样的环境场景，有着超过50种设计各异、细节丰富的敌方机甲。对战模式支持联网与本地分屏，提供欢乐爽快的乱斗体验。

音频项目背景

一个2d的横版动作游戏通常容易会给人一些类似“短小”“同人游戏”“4399”这样刻板印象，然而事实上《硬核机甲》拥有相当饱和的游戏内容，我们制作了连贯流畅而又不重复的8小时单机流程，从开发规模来说即使和主机3A还有距离，它也不是一个很小的项目了。开发过程中出现的各式各样的情况和问题对于一个小团队来说也是相当复杂。

为了保证开发稳定进行，截止到上线，项目使用的引擎最新版本为Unity2017.4.27/Wwise 2017.2.9，本文接下来提到的内容也均会依照该版本。

音频设计

让Wwise 3D适应横版游戏的虚拟实时定位衰减系统设计

音频组加入项目时游戏还只有多人的部分，接入Wwise后，我们首先遇到的问题是：如何让声音有定位？我们应该实现怎么样的声音定位？

为此我们参考了一些游戏，并在我们项目中进行了一些实验，发现虽然画面中的各种内容声源很朴素地从左到右摆放，但是我们游戏会有频繁的屏幕边缘已经屏幕外的声源，如果声源还在可见区域内偏右/左但声音就已经pan到了极左极右的位置的话，这种不自然的表现方式会导致玩家的注意力分散，丧失沉浸感。而另一方面，如果对可见区域外的声源的声像定位不明显的话，则又会误导玩家对发声位置的判断。

对于机甲游戏，不同于其他题材的游戏，游戏中几乎没有常见的foley、普通大小体量的交互音效等元素。而充斥着规格相当大的机甲音效，如果按照通常的游戏一样按声源的大小处理立体声宽度，那么其实基本上我们的游戏都是点声源了，机甲和机甲武器的厚重感会打折扣，为此我们希望音效能一定程度地展现立体声宽度，但又不能破坏玩家对声音的判断。

Wwise2017版本中处理声像定位有两种方法：

• 使用2D positioning，在所有音效上挂上2Dpanner的RTPC，发声时setRTPC来控制位置
• 使用3D positioning，开启GameDefine，里用listener和声源的关系确定定位
  

经过分析，我们判断第一种方法虽然比较直观，但没有办法将立体声的声源自由的处理成点状或者块状，并且这种方法需要给每一个音效传RTPC手动运算pan的位置，在每一帧进行快速刷新，在发声数巨大的情况下这样也会给程序部门的运算带来额外的压力。

使用第2种方法可以直接里用Unity的Transport来借助Wwise进行运算定位，但listener位置的处理以及它跟2d的边界管理就会成为一个问题。

最终经过考虑后，我们还是决定使用3D来进行制作。

于是首先整理下需求：

• 我们希望沿用Wwise的3d定位和衰减功能来让2d横版动作游戏的各种运动声音平滑的进行声像变化，这样可以获得较为顺畅的定位体验，同时比较好的控制开发设计成本和性能开销。
• 在画内时，为了体现机甲的体量，在画内时适当地让声源的表现效果是块状的
• 希望声源离开屏幕后能有一定程度的衰减和滤波效果，能清晰地辨识到左右画外
  

我们游戏使用了我们进行定制的ProCamera2D插件来管理镜头和渲染流程，这在赋予游戏多变的镜头和性能优化的同时，也导致项目中没有像常规3d引擎思路下的camera和z轴关系，所有内容都在一个平面上。而画面内容的变化时也没有实际上的camera物体对象的远近运动，是单纯地改变镜头。的CameraSize来实现画面内容的变化。

在这样的环境下，ProCamera2D只有一个锁定在画面中心的Object，如果直接把listener丢在这个所谓的“Camera”上，就会出现所有的声音都在极左极右的现象。

于是经过讨论与思考，我们为listener单独建立了gameObject，尝试让他单独处在z轴的一个相对位置，并让他跟随画面中心的xy坐标位置。这样一来，Wwise 的3D 游戏定义定位功能就可以正常工作。但这样一来，如图所示，Listener到声源的位置关系就变成了一个三角形的斜边，想实现“声音左右出屏变小”的话，3D 衰减设置中的max Distance就不在是线性关系，衰减曲线的设计和调试就变得复杂了。为了解决这样的问题我们使用了一套方案：

如图，假设该图中LR为玩家的横版画面的俯视图，L为左边界点R为右边界点，C为中心。设C到R为X，实际上，我们定义的这个画面长度LR是会放大缩小的，X的值也就会随着剧情的发展或玩家的动作而变化。

则Listener到画面边界的BorderDistance=√(x?+y?)，这个也就是画面边界的声源到Listener的距离，由于Wwise不能在游戏中通过RTPC实时调整attenuation的Max Distance，只能依靠程序来修改整个衰减的Scale，引出更多的计算。所以我们就直接在我们在程序中锁定这个BorderDistance的值，当画面拉近时X变小，那么只要反算出y的值（也就是Listener与中心C的距离），并根据y的值把实际的listener摆在对应的位置，即可在横轴上得到正确的衰减效果。

这样一来，不管镜头如何变化运动，玩家的Listener总是能在基于画面大小和固定的BorderDistance所演算出的位置，之后只要保持让3D的音效衰减设置的MaxDistance和BorderDistance相等，调整这个BorderDistance（MaxDistance）即可听到平滑的左右pan的效果。以此就可以进入下一步调整音量和频响上的衰减。

然而这里有两个问题，一个是这样一来衰减的范围对游戏的截面是一个弧形，如果中心线的范围正确的话，四个角的音效会到Wwise Attenuation的极限，另一个是一旦超过左右边界，声音也会到Wwise Attenuation极限。对于我们游戏，四个角都有一些UI，不会在这些镜头死角发生一些重要事件，但在战斗中声音毫无疑问是会经过这些地方的。

所以接下来我们希望在四个角或者已经出屏幕的声源在一定范围内能有一定的衰减，并且声像定位变化能更加明显，实现的方法也较为简单：提高wwise的max Distance的值，让他比程序的定值BorderDistance大一些，然后针对距离超出borderDistance的声音设计Volume、LPF/HPF等衰减曲线参数。注意这里除了动了衰减曲线之外，还添加了Spread的曲线，这样立体声宽度较大的声音在画内时，能拥有较为饱满、“块状”的声音表现力。

目前较新的版本中，Wwise使用了是否与Listener 关联Routing来代替的3d/2d的设计，position/orientation也可以混合使用，理解上更加直观化了，但如果用在我们项目中原理上并没有太大变化。我们因为种种原因没有机会使用该版本。

上文所述对于通用的机甲运动音效的情况，事实上对于各种各样的武器子弹、射击、场景交互物体等等，我们还配置了几种不同的衰减ShareSet，用于应对各式各样的状况。

比如图中的较为长距离的大规模光束武器，我们用了Maxdistance为5倍于普通机甲音效（BorderDistance）的长衰减，以实现让它在屏幕外很远的地方以极左右的声像给人预警。也会有一些场景元素比如火焰为了不过度干扰玩家等使用了较短的衰减，离开屏幕中心附近时很快开始变小。对于不同的子弹击中的物理效果，也都应用了不同的衰减模板，通常光束类会比子弹类远一些。MaxDistance上，都是首先大于listener到画面中心C的距离，然后向外定义各种东西的衰减长度。

塑造物理世界效果

对于硬核机甲这款游戏，机甲的类型、武器以及子弹的类型众多，这些各种各样的元素涉及了大量的材质，这些材质大量交互就会产生数量类型繁杂的音效和特效。Wwise的Switch功能可以很好的管理这些内容，但为了与特效系统的进一步整合，我们没有采用在Wwise中设置，而是在unity中设计了一套“物质效果系统（MatterEffect System）”以统一管理特效和音效。

该系统中，我们把材质对象分为Platform/Mecha/Bullet，按这三个类型互相之间的交互来配置脚步声、跳跃飞行落地、子弹击中玩家/场景/子弹等，整理为子弹对角色、子弹对子弹、子弹对场景、角色对场景四类、然后将音效使用Wwise Type接口和美术特效、震屏、手柄振动和镜头特效组织在一起进行配置。为了快速完成大量配置，我们还做了一些类似复制、批量编辑之类的编辑器功能上的优化。

相对应的，在Wwise中我们也使用了接近的结构来组织混音，下文会讲。

另外，机甲和场景接触的方法并不是只有移动和跳跃，为了丰富游戏的音效细节表现，机甲在接近地面时我们还设计了滑行扬尘的音效，这类音效我们归类为Tracking Moving Sound。我们使用了一个RTPC和扬尘的Blend Contener音效进行绑定，在特定机甲与特定材质的地面（一般是土/沙子）等距离较近并具有一定的相对速度时，会按照其滑行速度播放相应响度、样本厚度的声音。我们定义这个RTPC参数为speed，并且这个speed参数也和相应的特效大小按照一定的参数比例运算在一起。我们把它和前面的物质系统相结合处理了声音的效果。

这个参数还影响了部分不是用脚步而是使用滑行来移动的角色，我们为他们的移动声音设计了engine sound，把玩家的摇杆x轴偏移程度或者AI敌人当前的移动状态dynamic值(一个相对值，可以理解为AI的目标速度或者“油门”)定义为locomotion speed，并将该参数映射到RTPC来控制引擎的声音强度，而实际移动的speed则影响引擎声音的浑厚程度，通过blend container的不同轨道来实现。

我们在实际实现并测试该设计时，还发现这些数值的跳变比较激烈，玩家拨动摇杆的速度很快、角色的移动也会在近战对抗中产生快速的变化，这里我为所有涉及的RTPC都设置了一定的slew rate，让它们在程序传入参数时的变化有一定的渐变，模仿物理引擎的变速阻尼感，并取得了较好的效果。

营造沉浸感的细节

硬核机甲单机模式中拥有各式各样风格各异的场景、关卡，如漫天沙尘的火星矿坑，深夜中的营地、联通水下的秘密工厂，宇宙空间平台等等，这些关卡通过剧情、演出设计都给人带来了强烈的战争临场感。因此，音频上我们也必须尽可能的在这些关卡中找到元素，利用Wwise设计一些实时的表现，主动塑造一些变化来满足玩家对于沉浸体验的需求。

这里来举几个例子：第二章的玩家在雨夜潜入时，我们也简单引入了潜入游戏的一些常见的设计：我们根据玩家所处的“正常探索/被发现”的状态创作了两种对应phase的音乐，使用动态音乐系统切换，而当玩家被探照灯发现时，切换音乐的同时也使用了低通滤波器压制音效，配合一个紧张的音乐片段来刺激玩家，我们还刻意来为场景画面上制作了雨，雨声提供了丰富的中高频细节，而这种设计是为了迎合玩家躲进掩体时，将音乐和声音都用滤波器在bus上切掉500Hz以上的内容设计，以此来进一步塑造玩家神出鬼没的体验效果。

潜入关与水下关

第三章中玩家一上来掉入了一个巨大的水库，机体在水中重新启动向其中深入探索。我们同样采用了“先设计中高频细节，再切掉中高频细节”的策略。这次将玩家到水面的距离映射为RTPC，挂在音效bus的均衡上，当玩家深入水中时，中高频会随着高度愈发压低，而出水的时候中高频的迅速恢复加上水花声本身的高频，提供类似人类音效的体验。

第五章在一个大型天空平台中，玩家会频繁在室内、室外穿越，我们为此设计了一个RTPC区域，用于标识在一个trigger体内定向运动时，根据玩家在区域内X轴/y轴的位置映射变量到一个RTPC值，以此来切换室外高空强风和战场的环境声和室内的环境声以及混响的比例，塑造室内的挡风效果。

硬核机甲的九章单机游戏当中，每一章我们都找到了一些这样的点来运用Wwise的互动音频功能来主动营造声音变化，提升玩家的沉浸感。

声音设计

硬核机甲在声音设计上追求真实声音和日式动画音效之间的一种调和，我们希望一方面尽可能在声音内容上饱满丰富，另一方面又想追求旧合成器、拟音调出来的部分旧式感觉。为此我们引入了一些噪声合成调制，和采样合成器的运用，同时也采用了大量的实录样本来进行制作。

混音

结构组建

游戏的两种模式虽然都使用了接近的音效，但实际上，游戏的战局和目的截然不同，声音结构组织的出发点也截然不同。

对于单人模式，玩家所发出的声音和其他声音的逻辑关系是完全区分开的，声音的中心通常集中在主角身上，场景中有大量的敌人，也具有环境、音乐、音效等角色扮演游戏常见的各类要素，样本管理上应按照这些元素的分配来处理。

而对于多人模式，玩家着眼于快节奏的战斗，时刻关注着战局中其他人的状况，一个音效可以准确代表它所表达的角色，引导玩家思考应对的方案。应该按照角色来进行分配。

带着这样的思路我们触发，混音上，我们围绕着单机关卡部分和多人模式部分的听觉侧重点，战斗状况，样本的类型上的区别，将音效划分成两部分来进行混音，为他们搭建了分开的Actor-Mixer来进行组织。

结构上，我们基本上是以Unity项目内的各类程序系统和资源结构进行组建，这样能促使工程尽可能地贴合游戏的需求。

对于单人模式，我们面对的是线性故事流程中大量的武器，各式各样的场景物体和可交互物体，相对复杂丰富的物质系统，我们以这些不同的元素为中心进行整理，把机甲按角色运动动画、场景交互、射击武器、子弹的材质和打击对象、关卡里的各种内容等进行分离。并围绕着游戏项目中的各种系统为这些参数分别进行了混音上的处理。

而对于多人部分，我们则是按机体角色和对应的技能、武器进行的分类，并依照多人的衰减模式以及可能出现的分屏模式进行了音效管理。

动态混音与混音重心

对于单机模式，玩家所面对的始终是一个向前探索体验故事的流程，设计师需要留意玩家的注意力的聚焦点，针对性地进行设计。在我们的单机关卡，抛除掉UI玩家对声音的注意力首先在叙事线索上，其次到场景中关键的敌人（比如boss，精英敌人），然后到玩家自身的格斗、射击动作以及其对敌人的所造成的伤害反馈等等，最后到场景中的其他敌人，环境等等声音。

分析了游戏的相关行为后，混音首先围绕着这一点进行音量分布即可，分类丰富的声音元素的混音变得简单了不少。除了直接在项目中调整各个bus/ActorMixer的音量之外，我们还设计了一些RTPC来协调不同类型音效之间的关系，比如将部分较为主要的爆炸样本或大规模运动的音效上添加Wwise Meter插件并利用导出值来对音乐音效进行侧链压缩，并使用HDR来自动处理音量之间的关系，这些方式类似于ducking，但使用上会更加灵活，当优先级更高的的声音出现时，其他声音会变小为其让路。

然而实际上，仅靠这些系统性的设计依然无法让关卡流程的声音表现丰富，为此我们还单独创建并使用了一些RTPC/State当推子来在游戏中根据故事流程实时调整画面中出现的元素的比例，这些处理的目的在于放大玩家当前所需要注意的内容的存在感，突破固有的结构。并为玩家带来更为舒适的体验。

例如这里是关卡中出现的第一个机甲敌人，虽然和后面百上千的敌人一样都是杂兵，但我们创建了用state单独在这里放大了他的运动和开火音效，强化它作为第一个机甲敌人的存在感。此后也为其他和剧情相关的角色进行了单独处理。

第六章的两个STG关卡中，子弹、敌人的出现方式和之前的关卡大相径庭，之前数量较少的物体、武器及其子弹会大量频繁的出现，敌人数量也会在屏内迅速增多，为此我们运用State和Switch Container的组合来响应材质系统的参数，将部分样本音量缩小、应用单独的压缩器并做发生数限制。

硬核机甲的特色玩法之一是玩家有时可以脱出机甲战斗，也会有很多人类和机甲同时出现，然而机甲的大小自然大于人，如果人的声音在响度上和比例上和机甲相同，就会显得十分跳戏，经过思考我们决定处理成玩家在驾驶员脱出状态下，听人类的声音比例会大一些，反之在驾驶机甲时听人类的声音会小一些。

关于响度、动态范围、输出设备协调的思考与处理

我们游戏的发行会同时登陆主机平台和PC平台。对于这两类平台玩家的音响输出设备多种多样，主机平台主要以家庭音响/电视自带音响为主，部分玩家也会采用耳机来游玩。而PC平台则有家用音响，耳机、显示器音响，笔记本音响外放等多种多样的设备。而这两类平台上不仅仅是设备有区别，玩家主要游玩的游戏也有不小的区别，我们需要尽可能地满足各式各样设备的需求。

首先在平台区别上，对于PS平台，索尼在TRC审核时给出了指示性的响度参考：游戏通篇流程的平均响度规划在-24dB LKFS左右，该响度事实上和电影行业所使用的参考标准相同，我们使用Wwise的Loudness表和把音频信号录制并接入到DAW测试后，遵照该响度指示调整了各Bus/Actor-Mixer的大小使整体响度趋近于该值。但对于pc游戏尤其是独立游戏，这个平均响度有点过小了，PC玩家使用的设备更不确定，但类似显示器/笔记本自带音响通常输出能力较低，声音输出过小会限制游戏的表现力，为了协调这种差异，我们给pc定制了不同的混音策略，PC端的均衡响度会提到-18dB LUFS左右、动态范围也会稍小一些。

动态范围的改变上不只是输出设备响度之间的协调，事实上，我们还针对使用不同播放设备和不同条件的玩家采取了不同的策略来进行设计，并将其开放为一个设置参数来让允许玩家进行调整。我们希望通过设计来实现在高动态范围模式下，子弹擦过/机甲的小关节运动/背景环境元素之类的声音内容小一些，而主要的机甲运动、近战格斗等内容的声音等在混音策略中重要的东西则大一些，以此拉出一个符合我们游戏混音策略的大动态范围。低动态范围则反之。

为此我们使用了一个Dynamic Range的RTPC来控制整个HDR的threshold，但是一个机械自动的HDR并不能完全准确地判断出需要放大/缩小的声音有哪些，于是我将该RTPC借题发挥挂在了各式各样分类的Actor-Mixer/音效上来控制其Voice Volume。详细地依照前面的混音策略来扩大各个元素之间的音量差异来塑造动态范围。(大致直观点)

将Dynamic Range参数整理后，我们开放了两个设置供玩家调整，玩家可以选择播放设备来调整动态范围。考虑到玩家在耳机模式下底噪较小，我将耳机模式设计为比音响模式的Dynamic Range稍大一些，然后开放三个动态范围供玩家自行设置。这也是音频选项相对比较多样化的主机游戏常见的做法之一。

另外，播放设备的调整也跟立体声宽度有关，这个设置同时会影响Wwise的Channel Configuration和Panning rule(Speaker或者headphone的角度控制)。

牵扯到动态范围调整策略的声音元素

Ducking与Side-Chain

上文各个步骤中提到了大量的声音类型及如何利用并让混音尽可能地将各种元素在音量比例上拉开，然而游戏依然存在声音太过繁杂的问题，战局混乱时，重要的机体爆炸/剧情元素运动/台词出现时，浑浊的战斗音效依然在干扰这些关键声音的叙事表现。一味的提高这些声音的音量只会破坏声音的平衡，严重的时候会吓到玩家。

于是为了突出叙事中心，我们需要强化这些音效，首先想到的当然是为关键音效和语音添加Ducking。

然后很快出现了一些问题：制作人不喜欢Ducking的机械降低效果...

这其实是要求混音处理的更加自然一些，在让玩家清晰地辨识到叙事对象的同时，更不让玩家听出明显的系统处理效果。为此我们改用Side-Chain的方法来进行处理，首先我们使用Wwise Meter导出了部分爆炸音效和过场的音量值为RTPC，并用其反过来微调SFX的音量补正值。而对于台词我们使用了更加复杂一些的处理：我们在整理语音样本时测量了主角、队友、宿敌角色等几个关键角色说话的大致基频，每个角色使用的的频点不同，将这几个角色的mixer的音量用meter导出到一个RTPC，并在SFX的bus上使用eq效果器在对应的频段使用一个q值较低的eq引入该RTPC值，对这些频段的音量进行衰减。

分屏问题

硬核项目还有一个特别的问题：本地分屏模式

这是一款支持本地四人分屏对战的游戏，这里看起来似乎只是摆了四个摄像机对着四个人拍，然而事实上，我们游戏的四分屏都有相应的逻辑声源，如果简单的将摄像机和listener绑定，屏幕上的声音最多会发生十六次...这是一个发声数逻辑跟游戏逻辑混淆在一起的问题，不能简单地使用playback limiter来解决，必须加以处理。

首先按照原有的衰减模式的话，几个玩家是否在观测同一个声音会导致这个音效产生剧烈的大小变化，为了协调该问题我在两人以上的分屏模式关掉非操作物体（子弹、爆炸效果等）的3D衰减，然后在各个bus上根据玩家的数量对各actor-mixer进行了下压。每多一个玩家，各个mixer向下压6dB左右，不同的元素会有少量的差异。

相关阅读：

《硬核机甲》（Hardcore Mecha）的音频设计 - Part2

文/王健安
原文：https://blog.audiokinetic.com/zh/sound-design-of-hardcore-mecha/