下一代产品必须攻克的短板，在国内几乎找不到参考案例(13)

这样做才能满足“角色维持动作Loop状态，等待玩家点击”的需要。这是点击式镜头对话专有的需求。

这里可能会有一些相关的疑问：

一定要使用Clip/事件Repeater吗？不能用Marker或者单帧的事件点吗？

最好使用Clip。因为Marker或事件帧，只在演出序列播放到他们所在的帧位置时，才会触发事件。但在编辑时，你需要的是播放头放在任意帧位置上，就能看到角色进入该关键帧之前就已经进入的状态。而不是先把播放头放到Marker所在的关键帧上，让角色进入状态，再跳到别的关键帧上参考着这个状态编辑其他轨道。

没法在编辑时预览程序事件，编辑效率还是会下降

使用UE的模拟模式 （Simulation Mode） 。有些项目会因为关卡流送机制的魔改而导致模拟模式无法看到效果。此时建议写专门的功能，用于加载指定的关卡和角色。

而对Unity来说，想在编辑时预览事件类的效果，可能更容易从编辑器层面解决。

4.3 控制对话

经典镜头对话可以使用事件实现这些需要：

临时暂停，显示对话选项

根据不同选项跳转到不同的演出时间点 （通常来说，不同分支导致的结果，对应的只是同一演出序列中的不同时间段）

但点击式镜头对话因为有大量的暂停需要，使用事件就略显累赘。故而难逃魔改Sequencer或Timeline Editor，乃至单独设计演出编辑器的命运。

文本轨道可能是最常见也最核心的自定义轨道。该轨道通常负责显示每句对话的内容和时长，并在一句话说完时向序列播放器发送通知，让序列播放器暂停下来等待玩家点击。在有选项的情况下，还要在结束时调出选项列表，并根据选项结果处理向其他文本Clip的跳转。 差不多是这个感觉

当然，也并非一定要有这个轨道不可。替代方案是抄下来每一块Block的起始时间和结束时间，通过填表的方式控制播放。

而有些情况下，演出序列中必不可免的会使用Nav之类无法确定时长的程序功能，这就要求使用一些Marker或事件轨道控制播放。比如按状态回滚等，持续检测某个对象是否达成某个状态，如果未达成则回滚到此前的帧位，如果达成则向后继续播放。但也需要谨慎使用这类时序跳转节点，避免在有曲线轨道的情况下使用。

4.4 处理分支

在时间轴内处理大量的分支是极其痛苦的。

在这种情况下，更建议使用外部的流程图控制工具 （比如关卡蓝图） ，在外部控制选项、条件检查与变量更改等事件。根据不同的分支走向，播放不同的演出序列。