编者按 ：在行业寻求突破口的当下，国内下一代产品必须面对的一些问题，已经被清楚地摆在了台面上——工业化大家可能已经听到耳朵起茧了，但要说到最大的短板，大概还要数叙事/剧情/演出设计，换句话说，如何做好内容，是所有团队都需要思考的问题。
但与此同时，这些命题下的模块又极少有人能真正做好。就拿镜头对话来说，在国内几乎只有《原神》做到了相对具有规模和水平，大多数产品仍然需要从《巫师3》《赛马娘》等海外作品中拆解经验，更别提有相对系统化的理论指导。而下面这篇文章由实际的项目经验出发，总结了搭建一条生产管线的理念与流程，或许会对你有所启发。
本文由森一投稿，授权游戏葡萄发布。
以下为正文：
在为3D游戏项目设计剧情演出系统时，镜头对话会是一个不错的叙事方案。
但对追求高精细度演出的项目来说，真正开始做的时候，就会发现镜头对话是一个糅合了视听语言、角色表演、美术执行、技术探索的综合模块。面对这种跨领域知识互相牵连，错综纠缠的系统模块，想搭建起一条工业化生产管线，该用什么样的姿势入手？
今天就和大家聊聊这个话题——如何搭建起一条镜头对话的生产管线？
本文将分为以下几个部分展开：
镜头对话是什么
镜头对话的类型：欧美游戏的镜头对话和国产/日式游戏的镜头对话有什么区别
功能模块：怎么设计用于组装演出的“积木”
编辑器：该用什么样的方式制作演出
团队配置：国内现有的岗位介绍，以及前后协作关系
01
镜头对话是什么
追求影视化视听体验，把控资源利用效率，是镜头对话系统的核心理念。
镜头对话 （Cinematic Dialogues） ，通常可以理解为“有镜头感的对话”，或者“影视化的对话”。典型代表是《巫师3：狂猎》和《刺客信条：奥德赛》 （及系列续作） 。
二者不但把演出内容做得足以媲美插入动画，其后的技术讲座，也在游戏开发业界产生了深远影响。
《巫师3：狂猎》中的镜头对话
B站：BV1C4411G7od
从性质上来说，镜头对话是一种“插入性”的演出形式。它会打断玩家对游戏的控制赋权，让玩家没法控制角色和摄像机。只能像看视频一样用视听感官体验游戏。
但不同于插入动画 （Cut-scene） 。镜头对话不会在制作过程中投入过高的资源成本。插入动画会从分镜稿开始，驱动美术从无到有地制作出不可复用的动画成品。
而镜头对话更多的是利用现成的有限资源，满足不同情况的叙事表达需要。
也不同于站桩式对话——这种几乎不使用动画，也没有镜头构图的形式。镜头对话增加了构图、分镜、表演等要素，让剧情体验更接近于影视中的静态对话场面。
《艾尔登法环》不乏魅力的站桩对话
这就引出了实现层面的核心问题：
怎样设计出一套模块化的有限动画资源，并用这些资源做出复杂多变的剧情演出？
用《巫师3》技术动画导演Piotr Tomsinski的观点来看，这就像是“用一套积木，搭出无穷的组合”。
Behind the Scenes of the Cinematic Dialogues in The Witcher 3: Wild Hunt, Piotr Tomsinski, GDC ,2016
在进一步展开到模块的设计思路之前，首先要考察一下镜头对话的两种类型。这两种类型对应了不同的资源和技术方案。
02
两种镜头对话类型
按照对话系统中“是否需要玩家点击”，镜头对话可以区分为：
经典镜头对话：无需玩家点击。这种对话在体验上更像插入动画，基本还原影视体验，不会在每句话结束时进入静默状态，等待玩家点击。
点击式镜头对话：这种对话会在单句对话结束时维持画面和角色的行为状态。直到玩家点击，才会继续播放下一句对话及演出内容。可以看作是结合了视觉小说的形式而产生的变体。
点击式镜头对话大都会有个明显的对话框
对于大多数玩家来说，点击式镜头对话或许才是那个让人更觉亲近的形式。这是因为国产游戏和日式游戏大多都选择了这种形式，而开发者们选择这种形式的原因大体如下：
这种设计范式由来已久，在玩家群体中已经有了很高的接受度。
玩家有可能在剧情过程中随时离开，需要保证他能在回来时继续推进剧情。
手游项目的玩家基本不会开启音频，因此需要优先保证文字内容的传达效率。
这就需要对话文字能暂停一下，让玩家有时间看清。 （最有说服力的一个理由）
但点击式镜头对话也会带来这些设计限制：
插入动画和镜头对话将会变成绝对割裂的。没办法像《巫师3》一样做两种形式的无缝衔接。
动作表演会受限。人物总是要在一句话的最后进入动画循环状态。所以角色的动作也必须是“停得住”的。
情绪节奏会受限。表演必须在句子最后的部分进入静默等待的状态，因此要求单句对话的情绪点不能停得很高。
另外还有一个反直觉的现象。尽管点击式会在表面上显得更保守一些，但从开发角度来讲，点击式反而提出了更高的技术要求和更多的资源要求。这会在后文进行更详细的介绍。
03
演出模块的设计思路
该怎样用有限的资源，实现高质量的动画表现？
想达到这个目标，需要先把演出的构成拆解出来。从重要性来讲，可以优先考虑如何梳理表情、动作、镜头，三个模块。
演出表现类功能的大体构成
接下来会分节讲解他们的模块构成，以及如何设计更有表现力的驱动方案。
3.1 表情系统
想要实现出一套生动的表情动画系统，可以考虑把表情动画拆分为四个层级：
情绪：最基础的面部表现因素，指肌肉构成的表情状态
眼动：眼球的运动表现
眨眼：人类那些微妙而意义丰满的眨眼
口型：说话时的口部动态
这套思路是把情绪作为最基础的一个状态层，用作情绪传达的主体。而眼动、眨眼、口型三个模块则可以从情绪的动画层级中分离出来，当作叠加在其上的动态因素，用来提高表情动画的自然度。这样可以为每个模块找到最清晰的目标，无论是提升效果还是分析表演时的问题，都会更容易一些。
下文将会介绍一些打磨这些模块时得到的经验。
3.1.1 情绪模块
表情的意义在于传达情绪。也只有表达出情绪的角色，才能给玩家带来更深刻的印象。
而想要让游戏中的人物表现出感情，就要着手处理这三个问题：
状态：怎么让角色的脸部状态表达出精准的情绪
程度：同一情绪状态下，如何做出程度轻重的区分
动态：怎么在情绪状态之间切换，而且切换得自然
有三种可供参考的方案思路：
分段切换方案：把整张脸拆分成眉、眼、口三个段落，分别制作动画，拼在一起播放
整脸切换方案：整张脸切换动态动画，并允许单独覆写眉、眼、口等部位的曲线
混合空间方案：像调色盘一样混合角色的多个表情，得到一个新的表情
下文是对各套方案的详细讲解：
分段切换方案
《赛马娘》中的分段方法——《涙・瞳・汗までこだわる！「ウマ娘」3Dキャラモデル制作のノウハウを伝授》
分段切换的思路是把角色的脸拆分成眉、眼、口三个段落，分别制作动画，最后再拼到一起播放。通过组合“抬高的眉毛”+“瞪大的眼睛”+“愤怒的嘴巴”，就可以让角色做出惊讶的表情。
类似这样（不）
这样做有两个好处：
1. 更接近实际的表情运动规律。 如果做好各种各样的整脸表情动画，放在轨道上做混合切换，会发现角色的五官总会在某个时刻“一起开始运动”，并在某个时刻“一起停到某个状态”。这是极为不自然的。真正的五官运动，总是会有的先动，有的后动，有的动得快，有的动得慢。将脸拆分成三个段落分开运动，就可以很好地做到这个效果了。
示例：在Sequence中编辑分段表情动画
2. 节省美术资源。 制作成整脸的静态动画资源，会因为“嘴巴和眼睛的状态都一样，但是眉毛却不一样”的需要而制作出多个差分动画。毕竟眼睛的情绪表达力远超眉毛，而眉毛的情绪表达力又远超嘴巴。三个部位既不可能为了A动B不动而迁就着让表现力更强的部分静止，也不可能为了表现力更高的部位去排列组合出大量的整脸资源。
而把脸拆成三段分别播放动画以后，不但所需的资源量下降了，也不会有“脸上所有部位都在同时动”的怪现象出现了。
不过，这套方案也不是只有好处。
首先是分成三段时，配置的量会变大。三条轨道都要保证在精确的时间上达成精确的效果，就会造成工作量翻倍。
其次，权重曲线也不得不分成三个轨道去控制，甚至在要在每个Clip内部去控制。这也是极为繁琐的工作。
最后，只有面部高度概括的二次元项目才适合这套方案。对于相对写实的游戏项目，如果角色有鼻子部位、嘴周肌肉的表现要求，便没法应用该方案了。
而接下来要介绍的整脸切换方案，便是为了解决这类问题。
整脸切换方案
尽管分段切换能够让角色的表情不再时刻联动，可问题却正在于此。当角色需要整体进入“伤心”的表情状态时，演出制作者必须人为保证眉、眼、口三个部分在差不多相同的时间点切换状态，这样操作起来太麻烦了。
而把原本拆开的部位合在一起，不但五官的联动性会有所提高，原本三步操作也会简化成一步。而且，让美术同学做好完整的表情资源直接使用，情绪表达的精准性也会好于拆开再组合的效果。
这就是整脸切换方案的总体思路。也就是说， 分段切换是把一张脸拆开，而整脸切换则是把拆开的脸再拼到一起。
整脸切换的示例，高兴-愤怒-惊讶
但这样又变成了一动全动，说好的让五官分开运动呢？别急。把角色的整脸动画状态当成最基础的一层画布，新建一个覆写层 （Override） ，就可以实现“ 表情的多态继承” 了。
具体做法也很简单。在整脸动画的基础上，额外控制角色Morph （Blend Shape） 的曲线值，就可以了。
如果用Sequencer编辑的话，大概的感觉是这样的
比如，当角色整脸处于“微笑”状态时，覆写他的眉弓，修改眉弓的弯曲程度，就能实现出“尴尬微笑”的状态。
这样做的好处：
1. 更容易做出精确的表情状态。 无 论是策划也好还是美术也好，都不用再分开想象眉、眼、口各自应该有什么状态，并努力确保三个段落拼在一起时效果不会显得突兀。他们可以参考着原画的情绪差分图，在模型上还原出最为精确情绪效果。
2. 节省了演出的制作时间。 做好的基础表情可以满足70%的初级演出需求，演出设计者只需要处理好这一块就可以了。只有在必要时才会上手去做额外的轨道覆写。
3. 便于后续的自动化功能拓展。 使用浮点数控制角色的具体部位，可以便于让自动化程序接入控制。比如，可以根据某句话的语音振幅，生成眉毛和上眼皮的动画曲线，让角色的眉眼跟随角色的重音配合运动。
最后。这套方案允许眉、眼、口以外的表情构成元素参与表现，应用场景也便不局限于二次元项目了。
混合空间方案
无论是分段切换还是整脸切换，都依赖于独立的混合处理机制。这意味着情绪之间的切换往往共用着同一套混合机制，难以针对特定情况单独处理。
那有没有一种办法，能更直观且精准地控制情绪切换的过程呢？ 这时候就要考虑混合空间方案了。
混合空间像是一个表情动画的混色盘。把角色不同的情绪状态作为坐标轴的极点，在极点范围内找到一个中间值，就能得到一个程序混合出来的表情状态。比如在“高兴”和“愤怒”之间取一个中点，或许就能得到一个“狂气”的表情状态。
在高兴、愤怒、惊讶三点之间融合的效果
这套框架用两个浮点参数就可以同时控制状态和权重，演出设计者因此能够更精准地控制表情变化过程。无论想要什么程度的表情，想要表情之间怎么过渡，只要绘制曲线就能做到。
但由于两类参数均会造成状态和权重的同时变化，想人为手动地控制好参数变化并不容易。 最终幻想7R采纳了这套技术框架，前提也是有足够成熟的语音情绪识别技术，能够让程序自动完成基础的曲线绘制工作。
CEDEC 2020 FF7Remake的动画技术 - 知乎 (zhihu.com)
同样，这套方案允许更多的肌肉元素参与表现。但因为情绪状态数量受到插槽数量的限制，应用场景基本局限于写实类项目。
介绍完情绪的切换部分，下文将分别介绍情绪状态之外，能够让表情效果更上一层楼的相关模块。
3.1.2 眼动模块
人只有在充满敌意时才会盯着目标不放。大多数情况下，人的眼球会随着情绪状态，思考倾向，以及说话的语调而动态运动。这一点常常被开发者们忽略。
赛马娘的眼动效果
除了直接控制角色眼球骨骼的旋转值以外，还可以考虑使用混合空间。这样就能把眼皮的联动效果也做进来。
带有眼皮联动的眼动
在眼动模块的设计方面，可以留意这些问题：
大幅度的眼动，通常需要配合眨眼才能显得自然。
可以考虑预置一些模式，通过选择模式来快速配置眼动+眨眼的效果。
一定要保留自定义曲线模式让制作者自行控制眼动。
可以根据语音生成眼动的曲线值，节省制作者的时间。
可以考虑随机眼动模式，提高角色保持动作循环时的生动感。
随机眼动效果
3.1.3 眨眼模块
无论眼皮处于什么状态，角色都需要眨眼。而如果用传统的动画混合方法来实现眨眼，很容易发现角色会先把眼睛张得足够大，随后才做出一个眨眼的动作。
果冻眨眼问题
这是因为只有一份眨眼动画可用，而这份眨眼动画是基于角色的默认状态的。在混合时，角色的眼睛会从原先的大小混合到眨眼动画的起始帧，也就是默认状态下的眼睛大小，才继续播放后续闭眼的过程。
很显然，美术不可能为了每一种眼睛大小单独去做出更多的眨眼动画。提这种方案也会直接被打死。所以，这种情况下可以参考如下两种办法：
反复调试混合时长和曲线，让眨眼过程相对自然一些。
将闭眼状态当成目标状态，让程序处理角色眨眼，从任意状态插值混合到目标状态，再从目标状态混合回原本的状态。
两种方案用到的资源各有不同，但思路上大同小异。谨供参考。
3.1.4 口型模块
此处的口型指的是人物的说话口型动画。口型一般采用程序生成的方法，市场上目前有许多种方案，只需多加调研即可。方案选型时需要注意的是：
采用完全基于语音生成的口型动画，一定要提前明确配音与演出制作的流程关系。配音会卡死口型动画的产出时间。而表情是不可能不考虑语音和口型因素的，因此也会被卡住。
采用文字转音素，音素生成口型动画的方案 （文字带有时间） ，可以在配音文件进入项目前临时制作小样，但也免不了在语音文件进入项目后重新调整一遍。
一定要提前考虑好多语种适配的问题。能够多语种识别情绪的也将极大利于演出的整体适配。
尽量保证生成的口型动画格式是通用格式，以便动画师能及时调整效果。
当然，在不需要太过精细口型动画的演出中，你可以发挥有限动画的思路，反复调用已经做好的多种张嘴动画，将其组合出说话的感觉，适配语音的时长 （或者无语音） 即可。
另外需要注意，多数口型动画是不包含情绪的。因此需要保证口型动画可以叠加在角色的情绪动画状态上播放，以做出微笑着说话和噘着嘴说话这类的区分。
3.2 动作系统
动作系统方面要介绍的内容，以如何在保证效果的前提下节约资源为主：
分层混合：处理类似于下身动作相同而上身动作不同，或手臂动作相同而手掌动作不同的情况
衔接混合：处理不同动作之间，特别是循环类动作间的衔接
Look At：处理动作姿势相同，而头、身看朝向不同的情况
3.2.1 分层混合
分层混合允许在不同骨骼层级以下播放不同的动画。 简单来说，就是在角色播放某一份动画时，让其中一部分肢体 （骨骼） 播放另一份动画。比如下图就是让角色的上半身播放跳跃时的手臂动画，而下半身播放行走时的腿部动画。
演出做成这样还是找个电子厂吧
分层混合的主要好处是节省资源。 由于上半身的动画变化远多于下半身动画变化，分层混合可以提高有限动画的利用效率，在一定程度上节省资源。
通常的动画分层只需要分出上下半身就足够。在有必要的情况下，可以考虑把手部分出来。而如果还需要更大的自由度，可以允许演出设计者自由选择动画的分层混合等级和深度。
《赛马娘》中明显使用的分层混合，在此感谢Destin老师的倾情翻译
这个做法的实际应用已经相当广泛。比如《赛马娘》采用了手部动作覆写，《巫师3》则允许动画师选择具体的分层混合节点。只需要注意设计资源生产规范及应用规范，通常都能得到好的效果。
3.2.2 衔接混合
数量庞大的衔接动画，是否可以被省略？
循环动作之间的衔接处理办法，通常是点击式镜头对话系统最头疼的部分。也是许多项目的镜头对话难以取得效果的主要原因。
在点击式镜头对话当中，角色需要在每句话的结尾保持动作循环状态，等待玩家点击，并在下一句话开始后流畅地切换到新的动作，并保持住这个动作。
如果允许所有Loop动作之间均有衔接动画。
如果按理想状况来处理动作混合，在所有Loop动作之间都使用动画师制作的衔接动画，那么所需的资源量便是n(n-1)/2段 （n为Loop动画的数量） 。但这种随着状态增长而平方级增加的动画资源量是任何项目都难以接受的。
如果限制衔接关系，只允许特定动作可以实现跳转。 为了限制资源量，通常的项目一般会设置一个基准的Idle动作，将之作为各个Loop动作的中枢：
从Idle动作切换到一个Loop动作的衔接动作称为Start动作
从一个Loop动作到Idle动作的衔接动作称为End动作
所有动作必须回到Idle，才能切换到其他动作
这样一来，所需的衔接动画资源量就变成了2n。
这种做法效果虽差，但通常是策划、美术、程序三方博弈下来后都能接受的一个结果。动作加了一个弯，但确实可以换，对美术来说资源量可以接受，对程序来说技术难度也不大。所以很多项目都会采用该方案。
但在实际演出制作过程当中，又常会发现“回到Idle”这个动作过程总是会打破精心营造好的情绪氛围，而且会让角色显得像个恐怖的机器人。这是很典型的舍本逐末行为。但如果过于细究，又难免不被你想省事的同事吐槽几句。
而《赛马娘》介绍了一种插帧方案，来解决资源量和效果的问题。
使用程序算法计算两段动画的衔接混合，常常会遇到效果不自然以及穿模等问题，所以才需要美术制作衔接动画，保证动作自然。
但如果在混合时插入一个Pose帧，让Loop动作先在一定权重上混合到该Pose状态，再从该Pose状态混合向下一个动作的Start部分，就能一定程度上避免穿模与不自然。
这一思路相当于将Idle动作替换成了一个会被快速略过的Pose帧，用这个Pose帧来避免穿模和不自然的现象。
只要逐帧分析赛马娘的动作切换过程，就能发现这个中间帧是什么样子。
对比了几百帧，眼睛都快瞎了
不过，这一做法可能只适合于二次元风格的人物。更何况《赛马娘》的镜头是从正面给到的。关于写实风格的人物表演，恐怕还需要再多做一些方法探索和验证。
3.2.3 Look At
身体的Look At只需要处理头和上半身即可。
与眼动相仿。粗疏的Look At通常只需要分别控制腰和头的旋转值即可。而在追求较高的效果时，可以把Look At制作为动画混合空间，叠加播放到对应需要控制的骨骼上。
Look At中需要着重注意的是头部的自然运动。
CEDEC 2020 FF7Remake的动画技术 - 知乎 (zhihu.com)
人的头部很难保持僵硬不动，特别是在说话时。说话时头部保持不动的，一般会有高冷的气质，称为高姿态角色。
面对这种设计需求，还是需要考虑通过语音分析生成角色的头部运动曲线，让角色的头部跟着重音做轻微运动。
3.3 摄像机
摄像机功能主要解决的便是如何提供快速大量的构图的问题。 可以从两个方面着手 （本篇介绍的只是相对粗疏的做法，《刺客信条：奥德赛》的GDC技术分享中讲述了效果更为优秀的摄像机设计方案，对3C有更多了解的同学可以考虑深入研究。） ：
构图功能：能用人类 （至少是摄影师） 能够理解的语言实现构图的目的。
模板数据套用：能够把做好的构图拿出来反复用。
3.3.1 构图功能
为了让摄像机能够快速地围绕着被摄目标实现构图，首先要考虑的是为摄像机封装一批相对于拍摄目标运动的功能。
使用相机臂组件
这里以UE引擎为例。实现相对摄像机的最简单办法是使用相机臂组件 （Spring Arm） 。
来源：UE4官方文档
该组件不但让摄像机能够轻松做到相对于球心的运动，还提供了更为直观的设计语言。类似于水平拍摄角度、垂直拍摄角度、荷兰角、拍摄距离、画面偏移等常见摄影语言，都有着可以直接控制的对应属性。
有多个拍摄目标时的处理方法
只要摄像机能够找到两个对象的坐标，多人情况下的构图也就有了入手点。
首先，摄像机可以围绕两个坐标的连线中点做相对运动。
其次，摄像机可以根据两个坐标的距离和自身的FOV度数，计算出应有的安全距离。
安全距离可以保证摄像机绕关注点旋转时，两个目标始终都处于画面中一个相对固定的位置，不会出镜。
这样可以保证摄像机围绕着两个目标执行构图时不会有过大的表现偏差。而如果角色超过两个，个人认为首先应该检查场面设计是否出了问题。如果实在有必要拍摄群体镜头，可以考虑将群体划分为主群体和副群体，分别当成目标。或者找到场面中最重要的两个构图锚点。
肯定可以找到最重要的两个定位点的
便于构图的自动化功能
可以把一些想象得到的构图规范设计成自动化功能，通过程序提升实现效率。
比如这里的自动偏移功能。会在摄像机侧拍目标时，向被摄目标的视野前方水平偏移画面1/3的距离。并且随着摄像机围绕目标旋转到目标的正前或正后方时，偏移值逐渐缩小到零。
左：单人 / 右：双人
开启与关闭自动偏移的效果
这类功能只要能想到就可以尝试。注意以下几点：
注意耦合问题，各个功能都会影响摄像机的表现，所以问题排查起来会很麻烦
把自动化计算数值的功能尽量写成独立的功能，把运算和赋值分开，并且想好是要Tick还是要单次执行
3.3.2 构图编辑器
编辑器主要处理数据读写存和使用效率的部分。以实现过的经验而言，一个编辑器可以有这些模块：
摄像机列表：列出场景中已有的摄像机，方便操作与修改
预置构图类型：保存下来的预置数据组，用于快速得到一个构图
目标选择器：用于指定摄像机的关注目标
数据配置区域：属性操控面板，操控方式与引擎基本没有差别，但筛选掉了一些不必要的公开属性，稍微简洁了一些，更重要的是能避免错误的操作而导致繁复的Debug过程
在使用上，基本流程为：
新建一个机位
选中该机为需要关注的目标
选择一个构图，并查看效果
在选择的构图基础上进一步调整参数
可以选择保存参数，作为新的构图
将机位应用在时间轴中，一段Clip对应一个实例，可以转换为播放时生成的机位
这一流程目前还有许多值得探索和打磨的地方。易用性和预置构图类型的精准度都需要再做验证。总而言之，演出摄像机是一个同时考验镜头语言掌握能力和技术能力的部分，道阻且长，需多加努力。
3.2.3 让镜头动起来
想让静态构图动起来，可以考虑两个方案：
关闭相对相机的追踪Tick，将其作为静态摄像机使用。
也可以保持相对目标的追踪，使用偏移和旋绕等功能实现运动。
两种方法都可以直接在时间轴上拉曲线来实现精准的运动控制。但请务必注意， 在摄像机保持追踪Tick时，不要同时启用Transform轨道和相对运动属性的写入。
血泪教训。
04
编辑器
该用什么样的方式制作演出？
上一节主要讲述了与表现相关的功能的实现思路。当演出的表情、动作、镜头三要素已经具备以后，接下来需要处理的便是调度问题。也即如何制作演出，并将演出保存下来。
4.1 脚本之痛
笔者曾有幸参与过一些项目在搭建演出系统前的讨论，却不幸地发现无论哪个项目，最初都倾向于实现一套如下图般基于脚本的演出编辑器。
真的很努力想说明表格多难用
这种方法的基本思路是在对话表中为每一行配置表情、动作、动效等演出命令。在玩家观看每一句话时，便会同步触发相关的演出事件，在画面中看到相应的效果。
选择这种方案的主要理由有下：
程序实现难度低，很快就能跑起来
对演出设计师的技能要求低，只需能够打字便可处理表演
利用预置好的资源，可以很快做出五十分的效果
以往的2D游戏，或表演精度不高的3D游戏大多采用了该方案，因此可以看作是有技术和经验积累的方案
但，选择脚本，意味着这样的问题：
演出内容的触发绑定到了对话开始的时刻，但演出内容实际上是应该跟随语音变化的。这导致角色的演出动作根本匹配不上语音的情绪变化。而要想匹配情绪变化，则最多只能在语音中找到时间位置，在脚本上用类似于“延迟2.6秒触发”的方式实现。
脚本需要编译才能看到效果，甚至有的情况下必须实际触发对应的剧情才能看到效果。造成迭代困难，提升品质所用的时间成本大幅提高。
脚本依赖的其他系统元素过多，耦合性爆炸。任何一个改动都容易导致演出全盘bug。比如，对话脚本要求角色寻路到某个位置，但由于寻路算法后续有优化，导致所有调用了寻路的剧情都出现了问题。
难以同时触发两个以上的事件。脚本很容易变成像代码一样的逐行执行 （执行完第一句指令，采取执行第二句指令） ，导致演出穿帮。比如，本应该表情动作配合着一起做，结果变成做完动作再做表情。
基本可以认为，脚本是一个易于技术实现，却不易于产出高品质内容的方案。它可以让你用十分钟就做出一个可以看的东西，但想把效果打磨得更好，至少还要再花一到两天。对于有较高演出要求的项目来说，一定要慎重选用脚本作为演出制作方式。在没有硬性条件限制的情况下，尽量选择时间轴驱动的演出编辑体系。
《赛马娘》的技术讲座，专门讲述了使用脚本制作演出时面临的问题，只是图示的编辑方案更像是直接用文本编辑演出序列的源文件，而不是国内更常见的配表方法。
4.2 制作演出序列资产
对于点击式镜头对话而言，一定要注意：
减少在演出序列中（Sequence或Timeline）中直接使用动画序列的情况。更多地使用事件Repeater或事件Clip，在每一帧被播放时都向外部的演出元素发送同样的事件通知。
这个理念很难在一时之间想清楚，所以这里会讲得细一些。 按照传统的做法来理解，Sequence等序列资产是用来存放动画的。
这样的做法相当于把一个动画序列放进了另一个更高层级的序列当中播放。他们每一帧都是同步的，因而当播放头停在时间轴中间时，可以在画面上看到角色的动作也运动到了一半，且一动不动。
但为了适应点击式镜头对话的需要，演出序列不得不和逐帧转写动画数据的方式告别。
也就是说，演出序列不需要再存放动画，只需要记录用于改变角色状态的命令。而角色身上会有一个独立运行的状态控制器，当它接受到演出序列的通讯时，就会根据命令，控制角色做出指定的状态变更。
利用了很多的布尔、枚举、浮点参数控制演出，而非动画序列
这样做才能满足“角色维持动作Loop状态，等待玩家点击”的需要。这是点击式镜头对话专有的需求。
这里可能会有一些相关的疑问：
一定要使用Clip/事件Repeater吗？不能用Marker或者单帧的事件点吗？
最好使用Clip。因为Marker或事件帧，只在演出序列播放到他们所在的帧位置时，才会触发事件。但在编辑时，你需要的是播放头放在任意帧位置上，就能看到角色进入该关键帧之前就已经进入的状态。而不是先把播放头放到Marker所在的关键帧上，让角色进入状态，再跳到别的关键帧上参考着这个状态编辑其他轨道。
没法在编辑时预览程序事件，编辑效率还是会下降
使用UE的模拟模式 （Simulation Mode） 。有些项目会因为关卡流送机制的魔改而导致模拟模式无法看到效果。此时建议写专门的功能，用于加载指定的关卡和角色。
而对Unity来说，想在编辑时预览事件类的效果，可能更容易从编辑器层面解决。
4.3 控制对话
经典镜头对话可以使用事件实现这些需要：
临时暂停，显示对话选项
根据不同选项跳转到不同的演出时间点 （通常来说，不同分支导致的结果，对应的只是同一演出序列中的不同时间段）
但点击式镜头对话因为有大量的暂停需要，使用事件就略显累赘。故而难逃魔改Sequencer或Timeline Editor，乃至单独设计演出编辑器的命运。
文本轨道可能是最常见也最核心的自定义轨道。该轨道通常负责显示每句对话的内容和时长，并在一句话说完时向序列播放器发送通知，让序列播放器暂停下来等待玩家点击。在有选项的情况下，还要在结束时调出选项列表，并根据选项结果处理向其他文本Clip的跳转。
差不多是这个感觉
当然，也并非一定要有这个轨道不可。替代方案是抄下来每一块Block的起始时间和结束时间，通过填表的方式控制播放。
而有些情况下，演出序列中必不可免的会使用Nav之类无法确定时长的程序功能，这就要求使用一些Marker或事件轨道控制播放。比如按状态回滚等，持续检测某个对象是否达成某个状态，如果未达成则回滚到此前的帧位，如果达成则向后继续播放。但也需要谨慎使用这类时序跳转节点，避免在有曲线轨道的情况下使用。
4.4 处理分支
在时间轴内处理大量的分支是极其痛苦的。
在这种情况下，更建议使用外部的流程图控制工具 （比如关卡蓝图） ，在外部控制选项、条件检查与变量更改等事件。根据不同的分支走向，播放不同的演出序列。
4.5 生产效率
按照全人工的流程去制作演出，一个演出设计师需要在制作时处理以下若干问题：
是否能够在准确的时机上播放适当的人物动作？
是否能够让人物的表情匹配上语音的情绪？
是否能够让生成的口型动画匹配上语音？
是否能够在合适的时机执行剪辑？
镜头有没有关注当前语句描述的信息？
镜头构图是否妥帖恰当？
光照、音效、人物的头身Look At、眼珠的运动……
上述问题如果全都人为处理，就太过麻烦了。
而程序化生成 （procedural generation） 技术是制作镜头对话演出时，用于判断管线是否进入工业化阶段的关键标准。
程序化生成的作用是根据剧本以及相关配置，省却比较没有设计含量的认为操作，直接生成最基础的演出序列。序列中包含基础的分镜、人物动作、表情、口型动画等按时间点排布的资源，并且可以在生成结果的基础上再做调整。
有了五十分的基础，再打磨到六十分、七十分，就轻松很多了。
程序化生成演出的常见执行流程
按照Tomsinski的看法，生成器由三个模块构成：
剧本配置：哪些角色参与了对话，大体的情绪状态、行为状态如何
生成规则：演出设计师提供的算法规则池，比如什么样的情况该找到怎样的镜头构图，以及如何剪辑，等等
数据处理：调用资源，生成演出序列资产
按照这样的思路来看，这一部分确实需要的是一个既擅长视听语言，又懂得技术开发的，呃，技术导演。Tomsinski本身也正是作为技术动画导演一职于CDPR任职的。但无论国内是否具备相应的岗位和环境，想把镜头对话的程序化生成这一块吃透，这两方面的能力仍是必不可少的。
05
团队配置
5.1 相关岗位
演出策划：由策划部门管辖，更便于统筹资源和功能设计，当然也更便宜一些
任务对话配置师：由美术部门管辖，更便于质量把控，但在功能迭代上会薄弱些
当然，也有直接交给文案策划或者任务策划的。这类厂商可能会有传统古板，较难开设新类型的HC，或者一时承担不起专人专岗等问题。
5.2 演出制作的工作流程
确定编辑器的技术框架：通常是客户端和技术策划来处理。不过在有条件的情况下，也会交给精通技术、动画、导演知识的专人处理。
跟进剧本、关卡节拍、美术资源需求，确认现有资源是否能满足叙事需要。如果不能，确认需要追加怎样的资源。
提前设计小样供人预览，确认叙事思路。 （类似于分镜）
等待美术及语音资源进入项目后，在小样的基础上精调演出。
如果遇到任何bug现象，及时找客户端或技术策划处理。
提交，等待效果审阅，根据审阅意见反复修改。
最后，交由QA检验。
在管线稳定的情况下，手工制作演出，一天的产出量基本为长达20分钟的剧情内容 （语音累积时长） 。
5.3 继续探索
目前公开的，系统化的游戏演出系统建设理论相当有限。想做演出，往往就需要从观察现实开始，调研动画理论，根据零散的技术讲座及其只言片语推测实现方案，并不厌其烦地在技术层面调试出合适的效果，随后在深夜里品尝大量失败带来的挫败感。
对在研项目来说，这也需要团队整体有足够的魄力，能够接受员工对新方案的不断设想和尝试，并在员工受挫时积极支持这一块继续推动下去。
这一切的推动力都是表达。在没有“表达”作为驱动力的情况下，演出是最容易沦为“意思意思算了”的部分。
所以这也是笔者不推荐用“策划-程序-美术”这种经典的团队形式构建演出系统的原因。除非相关负责人都认可对叙事表现的追求，否则在尝试各种方案的过程中，对资源和效率的妥协，以及对失败的恐惧，都很容易压倒继续向前一步的探索欲。
笔者在此也很想感谢曾经信任自己，鼓励自己一步一步走进窄门的人们。特别是在我拿出无数多份失败的效果时依然给予我鼓励和帮助的组长，如果不是他放心把这些内容交给一个文科出身的剧情策划处理，信任这个人做出的东西的效果，并替他挡住许多外界的压力，这篇文章恐怕不会经我之手与大家相见了。
这篇文章在剧情演出的设计方面恐怕还很粗疏，但相信能帮助一些朋友在设计剧情演出前获得某一特定角度的观点，以便更全面地设计剧情演出。最后拿出更好的，感情更充沛的内容。这也是本文所期待的。
游戏葡萄招聘内容编辑，
点击「阅读原文」可了解详情
推荐阅读
| |
| |
| |
点击下方公众号名片，获取游戏行业更多信息
