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

但，选择脚本，意味着这样的问题：

演出内容的触发绑定到了对话开始的时刻，但演出内容实际上是应该跟随语音变化的。这导致角色的演出动作根本匹配不上语音的情绪变化。而要想匹配情绪变化，则最多只能在语音中找到时间位置，在脚本上用类似于“延迟2.6秒触发”的方式实现。

脚本需要编译才能看到效果，甚至有的情况下必须实际触发对应的剧情才能看到效果。造成迭代困难，提升品质所用的时间成本大幅提高。

脚本依赖的其他系统元素过多，耦合性爆炸。任何一个改动都容易导致演出全盘bug。比如，对话脚本要求角色寻路到某个位置，但由于寻路算法后续有优化，导致所有调用了寻路的剧情都出现了问题。

难以同时触发两个以上的事件。脚本很容易变成像代码一样的逐行执行 （执行完第一句指令，采取执行第二句指令） ，导致演出穿帮。比如，本应该表情动作配合着一起做，结果变成做完动作再做表情。

基本可以认为，脚本是一个易于技术实现，却不易于产出高品质内容的方案。它可以让你用十分钟就做出一个可以看的东西，但想把效果打磨得更好，至少还要再花一到两天。对于有较高演出要求的项目来说，一定要慎重选用脚本作为演出制作方式。在没有硬性条件限制的情况下，尽量选择时间轴驱动的演出编辑体系。 《赛马娘》的技术讲座，专门讲述了使用脚本制作演出时面临的问题，只是图示的编辑方案更像是直接用文本编辑演出序列的源文件，而不是国内更常见的配表方法。

4.2 制作演出序列资产

对于点击式镜头对话而言，一定要注意：

减少在演出序列中（Sequence或Timeline）中直接使用动画序列的情况。更多地使用事件Repeater或事件Clip，在每一帧被播放时都向外部的演出元素发送同样的事件通知。

这个理念很难在一时之间想清楚，所以这里会讲得细一些。 按照传统的做法来理解，Sequence等序列资产是用来存放动画的。

这样的做法相当于把一个动画序列放进了另一个更高层级的序列当中播放。他们每一帧都是同步的，因而当播放头停在时间轴中间时，可以在画面上看到角色的动作也运动到了一半，且一动不动。

但为了适应点击式镜头对话的需要，演出序列不得不和逐帧转写动画数据的方式告别。

也就是说，演出序列不需要再存放动画，只需要记录用于改变角色状态的命令。而角色身上会有一个独立运行的状态控制器，当它接受到演出序列的通讯时，就会根据命令，控制角色做出指定的状态变更。 利用了很多的布尔、枚举、浮点参数控制演出，而非动画序列