游戏界面的动效预演设计过程与引擎内还原过程，都需要注意的一个问题就是各个元素的层级关系。
我们将预演设计称之为设计过程，引擎内还原称之为落地过程。在这两个过程中都需要谨慎的处理各个元素之间的层级和切分关系。它们的这些关系统称为“节点布局”。这里的“节点”引用自Unity中预设体中的概念，形同PS中的图层与AE中的图层。
节点布局在动效中的影响因素，主要有几点：
第一，影响设计方案；第二，影响流程配合；第三，影响取巧形式。
第一，节点布局如何影响最初的设计方案。
在设计过程中，所有的设计基准，除了其他设计本身之外的因素外，主要需要考虑的是最终还原度的因素。动效设计师在设计过程中不能无限的使用各种效果和极度复杂的层级关系。因为这些效果或者复杂结构所对应的节点布局，在引擎内未必支持，或者引擎内做到同样的结构会非常麻烦。用更巧妙的方式，但更简洁的节点结构做出同样的效果，是一种经济的做法。
比如有些情况下，一些游戏中需要非常强的视觉效果时，会摈弃引擎内节点还原，而直接使用视频的形式（或者两者结合），这可视作是在包体与效果之间取得的一种平衡：
在引擎内还原对应设计效果时，也应该将已经考虑了一遍的节点结构，用引擎内特有的形式进行布局。另外还需要与前端进行配合，使设计效果既吻合设计初衷，又吻合其背后的程序逻辑。
第二，节点布局如何影响动效开发流程。
这两个层面是影响落地效果的关键因素。在动效开发流程模型中，我们提到，界面拼接的工作需要在前端将界面结构处理出一个基本的布局之后开展。动效工作则在界面拼接完成之后开展。由于界面的逻辑结构涉及到程序逻辑与动效逻辑两个层面，因此在每个界面的工作流里都应有充分的提前沟通，否则在动效拿到拼接好的界面时，如果发现其结构不支持自己的设计方案，会导致一些修改成本，有时候这个修改成本还会比较大。
比如最简单的，设计效果中做了结构拆分：
但引擎节点中未做拆分：
这时就需要拼界面工序重新对预设进行处理，之后才能继续动效工作。
这种情况还只是未涉及到挂载逻辑的节点，如果一个动作或者多个动作涉及到程序逻辑判断，则情况会更复杂，返工成本也会更高。
但是很多情况下我们并没有那么多时间去提前沟通，这就需要在项目前期培养出各个环节的配合习惯。如果有预演最好，但并不是每个人都可以通过观察预演来明确界面结构的细节的。最终还是落到一对一或者一对多的实际沟通。
对系统界面来讲，由于已经有很多通用样式和设计标准，因此这块的沟通量可能只会集中在前期。后期约定俗称之后的沟通量会降低很多。
但对于特异性的界面，尤其是临时性活动等界面，则需要根据具体情况进行充分沟通。虽然很多游戏的后期运营阶段，其活动类界面的基本框架是确定的，但仍然会有一些特别设计的结构需要去注意。
第三，节点布局如何影响取巧形式。
前文我们提过，在引擎中和在设计软件中实现同一种效果的方法大致相同，但很多情况下不尽一致。这也是前期设计效果时，设计师在制作某一个效果时需要同时考虑的事情。也就是说在设计软件中设计某个效果时就应该想到将来落地时对应的方案。如果落地时无法通过取巧的形式来达成，那么就不能设计对应的效果。
当然，这只针对偏后期阶段的预演设计。参考我们在动效开发流程模型中所提到的阶段，在“探索动效风格”第一阶段的第一步中是不用考虑这个因素的，在第二步需要逐渐开始考虑，第三步就需要处处考虑了。这直接决定着设计方案是否有落地的可能性。
具体的，在引擎中的取巧形式有很多。常见的有利用空节点、父节点旋转等。
比如在AE中实现一个这样的效果：
我们会用两个空节点去取巧：
对应的，在Unity中，可以利用两个空节点来实现：
又如，AE中实现一个斜向运动，但我们又需要单维度控制移动时，同样利用空节点来取巧：
对应的，也可以在Unity中用一个父节点去做类似的事情：
类似的取巧方式直接和节点的布局形式，比如是否可以增减节点相关。这都需要提前与前端进行充分的沟通，建立好规范（
包括但不限于节点的命名、规定可增减节点的部位等
），避免轻易更改节点造成的未知风险。
综上，为本篇全部内容。
欢迎点击下方名片关注本号
推荐阅读
本文来自微信公众号“COTA五号”作者：欧型兔（ID：cotadesign）。大作社经授权转载，该文观点仅代表作者本人，大作社平台仅提供信息存储空间服务。
