下一代产品必须攻克的短板，在国内几乎找不到参考案例( 九 ) 编者按：在行业寻求突破口的

文章图片
《赛马娘》的技术讲座，专门讲述了使用脚本制作演出时面临的问题，只是图示的编辑方案更像是直接用文本编辑演出序列的源文件，而不是国内更常见的配表方法。
4.2制作演出序列资产
对于点击式镜头对话而言，一定要注意：
减少在演出序列中（Sequence或Timeline）中直接使用动画序列的情况。更多地使用事件Repeater或事件Clip ，在每一帧被播放时都向外部的演出元素发送同样的事件通知。
这个理念很难在一时之间想清楚，所以这里会讲得细一些。按照传统的做法来理解， Sequence等序列资产是用来存放动画的。
这样的做法相当于把一个动画序列放进了另一个更高层级的序列当中播放。他们每一帧都是同步的，因而当播放头停在时间轴中间时，可以在画面上看到角色的动作也运动到了一半，且一动不动。

文章图片
但为了适应点击式镜头对话的需要，演出序列不得不和逐帧转写动画数据的方式告别。
也就是说，演出序列不需要再存放动画，只需要记录用于改变角色状态的命令。而角色身上会有一个独立运行的状态控制器，当它接受到演出序列的通讯时，就会根据命令，控制角色做出指定的状态变更。

文章图片
利用了很多的布尔、枚举、浮点参数控制演出，而非动画序列
这样做才能满足“角色维持动作Loop状态，等待玩家点击”的需要。这是点击式镜头对话专有的需求。
这里可能会有一些相关的疑问：
一定要使用Clip/事件Repeater吗？不能用Marker或者单帧的事件点吗？
最好使用Clip 。因为Marker或事件帧，只在演出序列播放到他们所在的帧位置时，才会触发事件。但在编辑时，你需要的是播放头放在任意帧位置上，就能看到角色进入该关键帧之前就已经进入的状态。而不是先把播放头放到Marker所在的关键帧上，让角色进入状态，再跳到别的关键帧上参考着这个状态编辑其他轨道。
没法在编辑时预览程序事件，编辑效率还是会下降
使用UE的模拟模式（SimulationMode）。有些项目会因为关卡流送机制的魔改而导致模拟模式无法看到效果。此时建议写专门的功能，用于加载指定的关卡和角色。
而对Unity来说，想在编辑时预览事件类的效果，可能更容易从编辑器层面解决。
4.3控制对话
经典镜头对话可以使用事件实现这些需要：临时暂停，显示对话选项根据不同选项跳转到不同的演出时间点（通常来说，不同分支导致的结果，对应的只是同一演出序列中的不同时间段）
但点击式镜头对话因为有大量的暂停需要，使用事件就略显累赘。故而难逃魔改Sequencer或TimelineEditor ，乃至单独设计演出编辑器的命运。
文本轨道可能是最常见也最核心的自定义轨道。该轨道通常负责显示每句对话的内容和时长，并在一句话说完时向序列播放器发送通知，让序列播放器暂停下来等待玩家点击。在有选项的情况下，还要在结束时调出选项列表，并根据选项结果处理向其他文本Clip的跳转。

文章图片
差不多是这个感觉