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

相关阅读：

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

整合

整合上，为了能快速尝试音频设计的效果，我们大量运用了Wwise Type进行配置，所有的声音配置和绝大部分的Game Syncs内容都是将Wwise Type写在Unity的各式各样组件中完成的。下面简要展示部分编辑器的内容。


角色动画编辑器与音效

我们项目的动画系统使用了Spine进行制作，并在Unity中写了单独的编辑器用来为spine动画配置响应的动画特效、程序事件、屏幕/手柄震动等等。音效的配置也和Spine在Unity内的动画事件管理进行了整合，在这种编辑器中，可以实现对音画同步的精细时间调整，进而最大可能地快速优化打击手感。

跟随动画进行配置时，因为并非所有动画都是预先调配制作产生的，而是由多个状态动画直接相互混合产生的，因此音效也需要根据实际声音的需求调整发生时机和权重。当两个动画混合播放时，按权重配置较大的声音进行播放。相对应的，需要在混合中播放的音效，也会通过它参与混合的参数比例状况做出一些参数上的调整。

Node Canvas与音效




我们项目中使用了NodeCanvas组件作为可视脚本编辑器来实现游戏中的各式各样的逻辑管理、角色行为树、角色动画状态机的可视化编辑，借此策划可以制作出相对复杂的逻辑、流程或动画效果。

为了让声音的播放和控制能在各式各样复杂的条件/时机生效，我们为状态机当中添加了wwise的通信以让他实时地控制wwise的事件播放、RTPC/Game sync调用的功能，借此我们得以实现一些条件相对刁钻的声音设计、条件判断，以及复杂的动态音乐轨道段落变化在玩家实时游玩当中做出相应的变化。而这种可视化编辑组件互相之间的通信更是频繁使用，让我们音频设计师能直接进行一些连续的或者是嵌套式的音频调用、控制设计。

过场编辑器与音效


硬核机甲中有大量的2d过场动画，这些动画都是通过spine进行散片素材制作，然后整合进入游戏播放，为了实现过场动画所需运镜、震动、震屏等效果的精细调整，我们使用了Slate这个时间轴编辑器框架，然后将spine以及其他我们所需要的功能对其进行了整合，同时为了实现声音、音乐配置的细致调整，我们也为slate制作了调用wwise事件的模块。

以此为基础，我们对大部分的过场音效都在样本阶段进行了拆分层，然后使用类似DAW的方式配置进游戏过场中，同时过场音乐和一些各式各样的实时音频系统处理也是用该方法进行配置。

但在实现过程中我们也遇到了很多各式各样的问题，作为以高精度过场动画为招牌的项目，保持音画同步是第一要务，然而因为多线程异步加载、后台性能的压力、编辑器与build版本中的性能不同、主机的性能不同等等因素都会导致过场中产生各种不同的卡顿/时间偏差所导致的音画不同步，这种问题会经常出现在只有过场或开头是个过场的场景中，音效可以依靠拆分大大缓解音画不同步带来的不适，但音乐是不能的，一旦问题出现，精心设计的踩准动画动作的过场音乐和画面错开还是会让玩家的体验还是会大打折扣。

大多数时候这类问题的正确解决方法是研究分析并正确处理并解决造成卡顿的根源。但我们还是为了保证音画同步做出了一些保险处理：我们在后台记录了过场中每一个拆分的Wwise Event在过过场中发生的相对时机，并利用Wwise SoundbankInfo当中记录的Duration信息在Slate中绘制了等时长的Action Clip，这些Clip在实际播放的时候每个单位时间都会检查自己播放的相对时间和slate的整体时机是否统一，统一则继续顺序播放，如果不统一则调用Seek On Event命令对自己进行校准。

除此之外，在长期打磨的过程中我们还为过场的声音添加了一些周边的功能：比如我们游戏允许玩家暂停游戏跳过过场，然而跳过时，声音的当前在播放的内容是否需要终止并不是固定的，这一点在音乐的处理上更为明显：有时可能已经进入了一条音乐后面的战斗中会循环的音乐，有时跳过快了又不会，为此我们也为每段cutscene添加了独立的skip事件表，依照表中的配置，一段过场中不同的镜头在发生跳过时，可以触发不同的skip event。过场中这些event或skip event是否需要在过场结束、过场中的组件销毁时播放，我们又设计了单独的接口部分进行管理。

发声对象的整合与Persistent Object的管理

Wwise的Event Post行为是基于对象的，一个声音的正确播放的生命周期总是需要一个GameObject来判断它的参数功能的作用范围。这里如何定义我们游戏的“对象”就成为了一个音频系统正确工作的关键，我们不能简单地将其任由程序post到发生代码的对象上。

首先我们在音频设计中规定了基本发生对象为“角色对象”：

• 玩家身上的各种发声体本身有很多是独立的（如开火、动画系统、特定的运动状态音效等），现在则将其全部统一在角色身上，以便让影响它声音播放的各种game sync正确工作。泛化运用动画系统跟wwise gameObejct的关系管理即可处理大部分音效画面内物体的音效。
• 我们将子弹和子弹的集中音效分离出来作为“OneShot对象”这类音效的特征是它们往往由角色spawn出来，并且生命周期有很大概率短于它声音的长度。此时我们会为其单独创建一个Object跟随他的位置，直到音效播完时销毁
• 其他顺应各种应用场合，往往不直接影响角色的声音事件的发声对象处理到“Controller Object”上，这些对象往往直接在场景中创建，和各种Node canvas的flow script通过Send Event或者指定发生对象进行协作，管理各种Game Sync或者音频控制。
  

另外，应对声音的长度长于对象的生命周期导致声音的不正确播放的情况。我们还2在大多数用到配置的地方都加入了Persistent Sound的选项，不同于上文的one shot处理方法当勾选时，这些音效统一在一个后台对象播放，该对象则会在游戏运行时不受场景、内部命令的影响一直存在。以便让它们接受各种全局处理的管理。

多人音效与网络同步

对于多人游戏项目，网络同步总是一个令人头痛的话题，物理距离和运营商/下级路由等等因素总是会给玩家之间的同步造成许多困难，不同类型的网络游戏为了应对不同的游戏规则和游戏细节，往往会采用不同的同步策略。类似格斗游戏和一些复杂游戏的设计，硬核机甲项目则使用了一套点对点回滚同步的系统策略，这也对音频系统的应对处理产生了影响。

首先简述一下这套Deterministic系统的基本处理方法：每个玩家会把自己的输入发送给其他的玩家，在这期间的延迟当中，游戏会根据这些输入对下数帧进行游戏运动模拟，游戏会在本地按预测的状况进行，并等数帧后其他玩家的输入到位进行校对，如果全部正确则往下进行，错误则回滚回出错的帧并重新根据其他多数玩家的真实输入计算出当前帧该有的状态。这样几名玩家在互相之间有延迟的情况下可以保证呈现给各个玩家的内容是正确的。同时由于模拟预测的存在让玩家能在感官上感受到几乎零延迟的体验。同时服务器也不需要实时运行游戏的全部细节，大幅减小同步的数据量开销。

关于同步的具体处理细节不做过多的叙述，在该系统下，Wwise在本地进行还放音效也会和其他画面和逻辑表现一起按预测模拟的内容实时播放，但此时当输入发生偏差进行回滚时就需要进行判断了。我们权衡各种情况的不同，把多人模式播放的声音分成了三类处理方法：

• 音乐和环境按起始逻辑播放不受回滚管理
• 通常的短音效播放时记录自己是否播放过，在发生输入不同步回滚时立即播放正确的音效，但如果重复则不播放。
• 循环音效播放时保持记录它自身的播放状态，并在发生输入不同步回滚时播放播放之前音效的stop，再判断是否播放新的音效。
  

依照这些逻辑运行游戏就可以让玩家即便自身网络环境恶劣，也能拥有尽可能流畅的声音体验。



音乐设计

工作量上讲硬核机甲的音乐是我整个项目音频工作的重头戏，整个项目音乐由我和高天祥、Eddy.Liu一起一共创作了60余首，近3个小时的原创音乐，其中挑选了39首相对完整的乐段进行混音编辑成原声集，现在已经在Steam发售，欢迎大家前去支持^_^


硬核机甲的音乐风格上来说，整体属于糅合日式游戏旋律风格的电子管弦乐，我们希望他同时拥有欧美科幻游戏中管弦音色和电子音色的协调，并且和战斗过程的调和，又能具备日式尤其是机战音乐朗朗上口令人热血沸腾的旋律。但其实创作过程中，二者时常会有些矛盾，现代游戏追求音乐的多样性，反复重复的音乐会让人听起来乏味，但对于日式游戏，重复强化日式的旋律主题来刻画角色、剧情又是必不可少的一部分，因此我们的日常工作很大程度上就是在权衡这两者，配合游戏剧情创作出符合剧情发展的音乐。

该项目的音乐创作理念上首先保证曲目的每首编配相对丰满，风格厚实的同时，在故事前半段我会多运用一些较散较短小的动机、不同花样的鼓音色以及相对旋律性较弱的音色和声音元素，强调氛围感和该曲目对场景的刻画，削弱曲目的旋律性和叙事感，后半段则逐渐反过来，大规模运用直接的二声部旋律来让战斗音乐的旋律主题感逐渐增强，并且通过在各种细节上对主动机的复用发展来营造叙事性。另一方面，作为同时负责音乐音效创作的优势，我还在鼓点、垫底音色中埋入了不少游戏内的音效，虽然玩家一般不会发现这些，但这种设计方法使得音效跟音乐的调和度不知不觉地大幅上升了。

从游戏的逻辑需求上来讲，随着游戏内容的开发陆续产生了背景战斗音乐，剧情战斗音乐，部分关键角色的角色音乐，过场音乐，配图对话音乐，界面音乐，还有多人模式的战斗音乐等需求。下面讲讲我们怎么应对这些音乐的逻辑应用配置和处理。

动态音乐矩阵的创作设计与关卡中的应用

我们游戏的战斗会随着剧情叙事的发展一直变化，在同一个场景中，故事会不断发展，战斗时而激烈时而平缓。我们同时需要强化这个场景的音乐主要动机，也需要顺应游戏音乐的需求同时具备激烈和平缓的部分，一条循环的音乐显然写得再好也难以应对这种需求，写太多的不同的曲子来回变也会淡化交代场景的功能。为此我为每个关卡创作其相应的动态音乐来应用在关卡的各个部分。

以第三章为例，首先从创作开始，我就将音乐结构化拆解为String（Woodwinds）、Brass、Key（Piano）、Guitar、Percussion/Drum、SynthARP/Ambience等几个部分，将曲子分成数个phase进行创作。


如图，首先按表我把不同Phase的音乐按图标拆解成了分层导出后，曲子变成一系列分轨，然后按照图中框架所示的搭建了Wwise内的音乐结构，P1对应的是一上来潜水中的部分，随后将其中一些可能会在同一个Phase内进行切换的分层按图中的颜色框选进行了复制组合。例如本例中phase3中的鼓是可以上下和phase2/4交换组合，弦乐可以和phase4的α主旋律相互切换。


另一方面，我为各个Phase之间写了一些Bridge Track来让他们切换时有过渡段落，比如第三章的Phase1阶段都用在玩家一上来落水的探索部分关卡，从水下关到陆地关卡切换时，经过一个短暂的Stinger后进入主旋律。


做好了框架后，下一步会针对关卡的流程组装框架中的曲目，我通常会先把关卡缩略到一块进行一个统一的流程规划，再在关卡中利用上文提到的各种编辑器等工具进行具体的配置。例如该图描绘了游戏第三章的26个区，这些区域中既有通过切区来切换音乐段落，也有在每个trigger触发剧情或锁区战斗时切换音乐段落的设计。


过场音乐的衔接处理

硬核机甲的精致的2d过场动画是游戏的一大亮点，他们分散在游戏中各式各样的地方，每个过场都有不同的触发时机和丰富的上下文，和游戏过程无缝衔接，这也为音乐的处理带来了一些挑战。由于过场和战斗之间没有切镜头无缝衔接，所以没有机会把过场音乐先停下来再播战斗音乐，用整条做好的音乐套过场又往往咬不住剧情镜头，我们只能一方面和动画组协调调整镜头长度，另一方面为这些曲子设计单独的intro段落，配合过场。

音乐很多时候直接停下来再另起并不是很舒服，而将音乐的切换卡死在过场结束的一瞬间显然不是个好主意，这会让曲子显得很跳。为了让音乐舒适地衔接起来，我们经常需要让音乐在小节正拍上进入下一段的功能，Wwise的Interactive Music中Music Switch Container很好地帮我们实现了该功能。

例如：第五章的boss战里，先会进入一个引入的过场，沃菲斯把主角塔雷瑟踢入世界树核心，一段嘴炮后进入第一段战斗，此时音乐进入段落A，敌人血量降低到一定程度后进入第二段过场，沃菲斯讲述自己故事后情绪激化进入第二段战斗，音乐从过场引入第二段的激化的战斗音乐，然后随着玩家击败boss再进入第三段过场。


如图，制作过程中出现的一个麻烦的点在于：玩家是可以手动跳过过场的，因此出现了图中的红色箭头-每个过场都需要设计一个单独的stop事件用于管理音乐各个分层播放的切换过渡、过场音效的停止，而玩家正常播放过场时，则按小节正拍节奏过渡到游戏当中。

通过音乐的设计，我们希望玩家能清晰地感受到情节的演进变化，又能把每一个章节的音乐和关卡中呈现出来。

以上是我对整个硬核机甲项目的一个总结，希望各位老师多多指点。


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