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

文章图片
在使用上，基本流程为：新建一个机位选中该机为需要关注的目标选择一个构图，并查看效果在选择的构图基础上进一步调整参数可以选择保存参数，作为新的构图将机位应用在时间轴中，一段Clip对应一个实例，可以转换为播放时生成的机位
这一流程目前还有许多值得探索和打磨的地方。易用性和预置构图类型的精准度都需要再做验证。总而言之，演出摄像机是一个同时考验镜头语言掌握能力和技术能力的部分，道阻且长，需多加努力。
3.2.3让镜头动起来
想让静态构图动起来，可以考虑两个方案：关闭相对相机的追踪Tick ，将其作为静态摄像机使用。也可以保持相对目标的追踪，使用偏移和旋绕等功能实现运动。
两种方法都可以直接在时间轴上拉曲线来实现精准的运动控制。但请务必注意，在摄像机保持追踪Tick时，不要同时启用Transform轨道和相对运动属性的写入。
血泪教训。
04
编辑器
该用什么样的方式制作演出？
上一节主要讲述了与表现相关的功能的实现思路。当演出的表情、动作、镜头三要素已经具备以后，接下来需要处理的便是调度问题。也即如何制作演出，并将演出保存下来。
4.1脚本之痛
笔者曾有幸参与过一些项目在搭建演出系统前的讨论，却不幸地发现无论哪个项目，最初都倾向于实现一套如下图般基于脚本的演出编辑器。
真的很努力想说明表格多难用
这种方法的基本思路是在对话表中为每一行配置表情、动作、动效等演出命令。在玩家观看每一句话时，便会同步触发相关的演出事件，在画面中看到相应的效果。
选择这种方案的主要理由有下：程序实现难度低，很快就能跑起来对演出设计师的技能要求低，只需能够打字便可处理表演利用预置好的资源，可以很快做出五十分的效果以往的2D游戏，或表演精度不高的3D游戏大多采用了该方案，因此可以看作是有技术和经验积累的方案
但，选择脚本，意味着这样的问题：演出内容的触发绑定到了对话开始的时刻，但演出内容实际上是应该跟随语音变化的。这导致角色的演出动作根本匹配不上语音的情绪变化。而要想匹配情绪变化，则最多只能在语音中找到时间位置，在脚本上用类似于“延迟2.6秒触发”的方式实现。脚本需要编译才能看到效果，甚至有的情况下必须实际触发对应的剧情才能看到效果。造成迭代困难，提升品质所用的时间成本大幅提高。脚本依赖的其他系统元素过多，耦合性爆炸。任何一个改动都容易导致演出全盘bug 。比如，对话脚本要求角色寻路到某个位置，但由于寻路算法后续有优化，导致所有调用了寻路的剧情都出现了问题。难以同时触发两个以上的事件。脚本很容易变成像代码一样的逐行执行（执行完第一句指令，采取执行第二句指令），导致演出穿帮。比如，本应该表情动作配合着一起做，结果变成做完动作再做表情。
基本可以认为，脚本是一个易于技术实现，却不易于产出高品质内容的方案。它可以让你用十分钟就做出一个可以看的东西，但想把效果打磨得更好，至少还要再花一到两天。对于有较高演出要求的项目来说，一定要慎重选用脚本作为演出制作方式。在没有硬性条件限制的情况下，尽量选择时间轴驱动的演出编辑体系。