Sumo Digital如何创作《Spyder》复杂的动画系统
By Sumo Digital资深程序员Nick Edwards和Sumo Digital资深程序员Andy Chapman |
2020年7月23日
屡获殊荣的Sumo Digital成立于2003年，旗下共有九家工作室、700多员工，分别设于英国的谢菲尔德、诺丁汉、纽卡斯尔、布莱顿（The Chinese Room）、利兹（Red Kite Games）、莱明顿矿泉城（Sumo Leamington和Lab42）和沃灵顿，以及印度的普纳。Sumo为微软、索尼、世嘉和2K等大牌发行商成功开发了各种平台与体裁的游戏，其游戏作品以老少皆宜、技术独到和善于创新著称。
Sumo Digital是Sumo Group plc.的一部分。
要了解更多信息，请访问：sumo-digital.com。
大家好，我们是Sumo Digital资深程序员Nick Edwards和Sumo Digital资深程序员Andy Chapman。Sumo Digital经常会举行内部游戏创作赛会，并给优胜作品提供进一步开发的机会，以扩展其概念。使用虚幻引擎技术的《Snake Pass》就是在先前的游戏创作赛会中胜出并投入制作的例子，它最终实现了多种平台版本的成功发售。
《Spyder》是通过这一流程脱颖而出的最新作品。在一场游戏创作赛会中赢得优胜后，由三名设计师组成的原团队得到扩展，继而制作出一个很有吸引力的营销演示，使《Spyder》在Apple Arcade上赢得一席之地。这也意味着我们必须确保这款游戏能在iPhone 6这样性能平平的移动设备上运行。随着这款作品进入正式制作阶段，团队也进一步扩大。我们就在此时参与制作，用C++重写了原有的基于蓝图的Agent 8原型，意在使它更有个性、更容易维护和有更好的性能。
我们将在这里为大家详细说明为实现这些目标所需的工作。
《Spyder》是通过这一流程脱颖而出的最新作品。在一场游戏创作赛会中赢得优胜后，由三名设计师组成的原团队得到扩展，继而制作出一个很有吸引力的营销演示，使《Spyder》在Apple Arcade上赢得一席之地。这也意味着我们必须确保这款游戏能在iPhone 6这样性能平平的移动设备上运行。随着这款作品进入正式制作阶段，团队也进一步扩大。我们就在此时参与制作，用C++重写了原有的基于蓝图的Agent 8原型，意在使它更有个性、更容易维护和有更好的性能。
我们将在这里为大家详细说明为实现这些目标所需的工作。
动画
最初的步骤
在我们开始开发主角Agent 8的最终版本之前，我们审查了为游戏创作赛会制作的角色早期迭代和《Spyder》的原型。我们的美术师和动画师们想让这只小蜘蛛显得更有个性，但是用早期版本中采用的程序性动画很难做到这一点。放弃程序性动画方法带来了无数挑战。我们需要一套骨架，它必须有足够的骨骼来表现多腿角色，但又不能多到妨碍我们在目标移动平台上使用GPU蒙皮计算。为了不超出开发、磁盘和内存预算，我们需要避免创建超大的运动动画集。所以，我们需要改造有限的动画集来解决在多变的环境中通过完善的用户控制进行导航的问题。
为Agent 8配备（外）骨架
要实现以美术驱动的方法来表现角色，一个至关重要的条件就是为这只小蜘蛛创建一套骨架，使我们的动画师能够让Agent 8活动起来。创建这套骨架是个挑战，因为腿的数量会导致骨骼数超出我们的目标移动平台为GPU蒙皮计算规定的75块骨骼的限制。一旦超出这个限制，虚幻引擎就要改用CPU蒙皮计算，这会带来严重的性能影响。好在我们可以深入引擎代码进行修改，使其在ES3.1平台上使用Metal API支持多达256块骨骼。你可以通过GitHub上的提取申请（需要登录）来找到我们所做的更改。因为《Spyder》是个Apple Arcade作品，我们的所有目标平台都会使用Metal API，所以这个API不成问题。
找到我们的脚
要为Agent 8制作动画，最有挑战的部分就是处理这么多腿以及它们与环境交互的方式。在大多数游戏中，角色都是在一个平面上移动的。在上下斜坡或楼梯时，胶囊体保持垂直状态，开发者使用逆向运动学（IK）来防止脚的动画穿过地面。从脚的当前位置上方一定距离到其下方一定距离进行物理追踪，就可以找到应该约束脚的表面。对于Agent 8，需要用一个不同的解决方案来处理，使该角色能够同时跨环境中的多个不同平面移动。做“反应式”IK是不够的，因为最终脚会沿着各个平面拖动，但是在某些情况下Agent 8应该预见到自己要移动到不同的表面上，从而调整腿的移动弧线，例如走上一面垂直墙。许多可能的几何体组合意味着我们只能为一个平坦的XY平面生成动画集。因此，我们需要开发“预测式”IK，来解决上文的爬墙例子之类的案例，要让角色预见到自己要移动到不同表面，从而相应地扭曲动画。
此图显示了我们要实现的基本结果。
当静止站在外角处时，找到IK Agent 8的正确落脚位置是个比较简单的任务。一旦它动起来，就会出现更多问题。我们需要估计每只脚落下的位置，这样我们才能扭曲行走循环的动作，使它爬上墙或翻过边缘。否则，角色就会拖着它们的脚穿过要爬上的墙壁或要翻过的角落。
Agent 8的预测式IK能够预见将要落脚的位置。
我们对运动动画使用了动画修饰符，以计算和存储脚在分量空间中离开和到达的位置。首先，我们的动画师制作出带有根动作的所有动画，这样我们就能确定动画的所有帧的工作。然后，动画修饰符标记动画中落脚的时段（脚部骨骼位于或邻近Z=0 XY平面）。然后对于每个帧，我们可以计算当前根变形和脚踩到平面的记录位置的根变形之间的相对变形。然后我们将这个相对变形与脚落下或即将抬起时的组件空间位置相乘，得出最终的值。我们将这些位置矢量分解成它们的X、Y和Z分量，把它们存储在动画中不同的浮动曲线中。每只脚的每个到达位置有3条浮动曲线，每个离开位置也有3条，因此共有36条浮动曲线。
目标脚位置编码为每条腿的浮动曲线和矢量分量。
动画修饰符生成到达和离开脚位置。
全域追踪
有了用来判断将要抬脚和落脚位置的数据，预测式IK就有可能实现了。用于查找IK目标位置的所有逻辑都包含在一个自定义的动画图表节点中。最初，我们在AnimInstance中实现它，但是这带来了延迟，会产生不准确的结果。我们需要让相关动画运行，使得最新的曲线数据能够用于采样，然后执行我们的追踪和计算，再更新可以让LegIK节点提取数据的虚拟骨骼。虚拟骨骼的作用就是担当一个暂存区域，使不同的动画图表节点之间能够共享变形。在理想情况下，我们会把动画图表节点的因数析出到更适合复用的片段中，我们认为将来等Control Rig达到产品级要求，就能用来解决这个问题。这里再深入讲一下关于我们的自定义动画图表节点如何使用这些数据的实现，我们首先在Agent 8的骨架上为每条腿定义了一个静态参考插槽，从这个插槽执行到离开和到达位置的扫描球体追踪。这些插槽大致就位于每个基节。当蜘蛛在一个平坦表面上时，这些追踪的结果应该就是它们的端点。在与垂直表面相邻的表面上，某些腿的这类追踪结果就会命中垂直表面。在与边缘相邻的表面上，某些腿的这类追踪结果将不会命中任何东西。
这张插图显示了我们在表面发现中使用的众多追踪中的三个。
如果第一个追踪没有命中，我们就执行附加追踪来查找表面。我们使用了一系列预定义的技术，按照它们的成功概率排序。第一个附加追踪从到达/离开位置直线向下执行，以查找稍有弯度的几何体（例如大型球体）上的表面。如果这个追踪失败，我们就从前一个追踪的端点朝向蜘蛛执行对内的反向追踪，以处理许多简单的外角。我们会继续执行追踪，直到获得命中结果。如果我们什么都没有找到，就回到初期，什么都不做。
一旦我们找到一个表面，就会进行一些数学计算，根据多个变量来判断脚在表面的位置。其中一个变量就是可以合理落脚的距离，使用基节和到达脚位置之间的当前距离来确定在腿没有过度伸长的情况下脚可以够到的大致范围。
一旦我们找到一个表面，就会进行一些数学计算，根据多个变量来判断脚在表面的位置。其中一个变量就是可以合理落脚的距离，使用基节和到达脚位置之间的当前距离来确定在腿没有过度伸长的情况下脚可以够到的大致范围。
我们不想要过度伸长这种腿伸展方式。
在相关表面上“投影”目标脚位置之后，我们执行附加的物理追踪，来确定脚是否仍然在表面上。如果不是，我们就重复执行以上过程来查找另一个表面，然后尝试在该表面上投影。我们的投影逻辑有足够的可靠性，可以处理具有完全背对我们的法线矢量的表面，因此当Agent 8伸出一条腿，绕到完全在其视野之外的表面上时，我们能够很好地确定落脚位置。
需要注意的一点是，在大多数情况下，我们都会把追踪加倍。《Spyder》对于大多数环境和对象，会使用两个独立的复杂碰撞网格体。一个是渲染网格体的“简化”近似（仍然是三角网格体，但是细节较少）。另一个是完整的渲染网格体碰撞本身。角色运动系统和摄像机系统是简化碰撞的主要用户，而渲染网格体碰撞只有动画系统才会显式使用。简化的碰撞基本上与一个“可行走”碰撞信道关联，渲染网格体则与可视性信道保持关联。IK的追踪同时使用这两者：简化的碰撞更适合用来广泛地感知可能的落脚点，因为像铆钉之类的环境元素在这种碰撞中不会表示出来。我们使用渲染网格体碰撞来确保脚落在可见的几何体上。
关于性能的说明。考虑到我们的一些目标平台的规格和我们查询的碰撞的复杂程度，我们起初很小心，不敢执行过多追踪。实际上我们太过谨慎，以至于许多早期IK工作在每帧对每条腿都只使用一个追踪，使用动画通知来切换追踪目标。我们甚至考虑在目标脚位置变化时只执行一次追踪，完全放弃每帧追踪的做法。但最后我们发现，执行追踪的成本并没有我们以为的那么大。在我们最终提交的实现中，我们对于两种类型的碰撞都在每一帧根据每只脚的离开位置和即将到达位置执行追踪，直到有一种追踪策略成功为止。因此，当Agent 8在复杂的几何体上遍历时，这套动画系统能够每帧执行多达200个物理查询。如果有必要，我们会优化它，但是因为只有一个角色执行这个逻辑，所以这对于总体帧时间没有太大影响。
需要注意的一点是，在大多数情况下，我们都会把追踪加倍。《Spyder》对于大多数环境和对象，会使用两个独立的复杂碰撞网格体。一个是渲染网格体的“简化”近似（仍然是三角网格体，但是细节较少）。另一个是完整的渲染网格体碰撞本身。角色运动系统和摄像机系统是简化碰撞的主要用户，而渲染网格体碰撞只有动画系统才会显式使用。简化的碰撞基本上与一个“可行走”碰撞信道关联，渲染网格体则与可视性信道保持关联。IK的追踪同时使用这两者：简化的碰撞更适合用来广泛地感知可能的落脚点，因为像铆钉之类的环境元素在这种碰撞中不会表示出来。我们使用渲染网格体碰撞来确保脚落在可见的几何体上。
关于性能的说明。考虑到我们的一些目标平台的规格和我们查询的碰撞的复杂程度，我们起初很小心，不敢执行过多追踪。实际上我们太过谨慎，以至于许多早期IK工作在每帧对每条腿都只使用一个追踪，使用动画通知来切换追踪目标。我们甚至考虑在目标脚位置变化时只执行一次追踪，完全放弃每帧追踪的做法。但最后我们发现，执行追踪的成本并没有我们以为的那么大。在我们最终提交的实现中，我们对于两种类型的碰撞都在每一帧根据每只脚的离开位置和即将到达位置执行追踪，直到有一种追踪策略成功为止。因此，当Agent 8在复杂的几何体上遍历时，这套动画系统能够每帧执行多达200个物理查询。如果有必要，我们会优化它，但是因为只有一个角色执行这个逻辑，所以这对于总体帧时间没有太大影响。
动作扭曲
有了用于查找离开和到达脚变形的逻辑，我们就需要用它对动画施加一些影响。我们的思路是，把原动画的地面平面扭曲到我们使用这些变形生成的样条上。我们在分量空间中还是有离开/到达位置的参考点，通过使用它们，我们可以得出脚在这两个位置之间的当前位置的alpha值。使用这个alpha值，我们可以在样条上确定一个要使用的点，它就成为我们新的“地面”位置。接下来，我们计算从参考地面位置到脚的当前位置的相对变形，然后将这个相对变形应用到新的样条地面位置上。结果就是使用我们新扭曲的地面“平面”得到的脚应该在的位置。无论遍历的几何体是什么，都会使用这同一套运动动画。
对蜘蛛的所有脚执行这一过程后，我们把这些计算的结果推送到一系列虚拟骨骼中，后者再把它们传送到LegIK节点，由该节点实现FABRIK IK解算器。LegIK节点具有每条腿四块骨骼的链条，是用于我们的蜘蛛的现成选择。
表面发现对于确定落脚位置至关重要。
动态
除了腿部的工作外，我们也花时间打磨了角色动画的其他方面，主要是改进了Agent 8的其他身体部位在移动中的响应方式。触角
其中一个方面就是Agent 8的后盖中安装的天线触角。这些触角的作用不仅是为我们的主角提供接收无线电通信的手段，也可以帮助体现角色的朝向。因此，我们必须根据这些触角相对于重力的方向，引入一些动态机制。为此我们利用了AnimDynamics节点，为属于每个触角的骨骼链提供动作。我们的动画师在这个节点上试验了许多设置来产生他需要的结果，在这个过程中我们不必编写任何自定义代码。我们不仅做到了让触角根据重力倾斜，还在Agent 8四处移动或处于悠闲状态时获得了很好的辅助动画。这给角色增加了一些活力和额外的情趣，而随着开发工作的进展，触角也被大家亲切地称作deeley bopper。
Agent 8的触角会根据朝向的改变而作出反应。
身体
在使触角动态化并对腿部IK做了足够改进之后，我们又思考了怎样才能对Agent 8的身体应用物理反应。最初我们是想再现重力对蜘蛛身体的影响，使它在上下颠倒时身体垂下来，离落脚面远一些。这就需要修改主身体骨骼的变形，提供平移和旋转偏移。由于其他所有系统都还没有完成，这将导致包括腿在内的整个网格体发生偏移。在使用分量空间IK的情况下，这不是问题，因为腿会重新指向身体移动到的位置。在我们证明用重力影响身体的过程令人满意之后，我们就考虑实现其他效果。从项目一开始，在角色小组里就经常讨论一个想法，那就是让Agent 8具有重量感。在起动和制动时，或者静静地贴在移动的物体上时，身体都要有相应的位移。为了做到这一点，我们使用了一个瞄准蜘蛛的实际位置的矢量串，从先前的身体串位置向它进行插值。在某些情况下（例如在制动时），我们会在身体串位置加一个力，以增大身体得到的摇摆量。我们还使用当前的身体串偏移来产生俯仰和横滚，再将它们和平移偏移一起与重力效应累加，然后应用到身体骨骼。
Agent 8的身体串会产生有趣而动态的运动。
小装置
Agent 8与场景交互的主要方法之一就是使用各种小装置。游戏中有好几种这样的小装置，在玩家的通关过程中，每一种小装置都有助于为玩家提供颇有实感的体验。每种小装置都能提供独特的体验，因此要以不同的方式来控制和制作动画。我们在编写小装置时使游戏性行为与动画本身脱钩，也就是说我们可以全面控制它们在使用时的外观。它是怎么做进去的呢？答案就是蜘蛛科技。
每种小装置都有一个包含其物理表示的关联Actor类，而且每个小装置至少包含两个骨架网格体组件——一个是机械臂，另一个是装置头。机械臂的骨骼是在所有小装置之间共用的，而每一种装置头都有自身独特的骨骼。我们利用Copy Pose From Mesh动画图表节点将共享的骨骼变形从Agent 8传播到机械臂，再从机械臂传播到装置头。大多数小装置都有动画蓝图实现不同类型的手动计算IK，从而产生所需的效果。
确保IK对于每种悠闲动画都有足够好的效果是关键。它们与我们开发IK系统时用于对照测试的运动动画有很大不同。好在我们创建的解决方案只需要一些微调和修补就能让这些新动画产生出色的效果。
情感反应
既然能够全面控制Agent 8的动画，我们就想开发一套情感反应系统，进一步突出它的个性。在游戏中实施特定的行动或者进入特定的地点，都会激发某些情感，使得主角在漫步时出现别样的面部表情，或者站立不动时触发悠闲/烦燥的动画。游戏中有12种情感，我们给每种情感至少制作了一种悠闲和烦燥的动画。我们通过动画图表中的一个自定义节点的实例来播放它们。这个自定义节点类似于Random Sequence Player节点，不过它会根据概率从一个列表中选择一种动画，以随机的播放速度循环播放随机次数，然后停止播放。这样一来，我们就能在节点的两种实例之间过渡，每种实例都有一套不同的动画、百分比概率、循环次数和播放速度。确保IK对于每种悠闲动画都有足够好的效果是关键。它们与我们开发IK系统时用于对照测试的运动动画有很大不同。好在我们创建的解决方案只需要一些微调和修补就能让这些新动画产生出色的效果。
运动
360度导航和运动自由既是祝福也是诅咒。虽然这让玩家获得了在传统三维游戏中不一定有的大量自由，但也可能给开发者造成几个很头疼的问题。当玩家开始在墙壁和天花板上行走时，传统第一人称和第三人称游戏中常用的控制和摄像机等系统就会崩溃。问题
我们在项目早期就列出了许多限制，其中既有设计要求，也有工时的限制（我们要赶上截止期限，还要生成大量关卡内容）。- 不能有关卡标记或提示（也就是说：“这是一面墙”、“这是一条边缘”、“这是一个角落”，等等）。这是一个工时限制。我们没法始终控制不断演变的关卡布局。
- 形态比较自由的几何体：因为真实世界不是基于网格的。
- 移动的表面：静止不动有什么意思？
这样就确定了一个事实：由于我们规划的关卡几何体的潜在复杂性和偶尔的动态性质，我们必须想办法实时发现小蜘蛛所处的局部环境。
简单的开始
我们知道必须执行某些追踪来确定小蜘蛛周边有哪些表面是可以供它行走的，于是就首先以浮动的Pawn移动组件作为基础，然后增加了重力和一个对它进行多重球体追踪的调用。顺便说一下，我们在执行零长度的球体追踪时遇到了一个问题，引擎会检测到它，并在x轴IIRC中将长度强制设为1。我们将这个注释掉了，后来它似乎就没有造成任何问题。
这个浮动Pawn解决方案在快速制作的测试关卡中提供了令人鼓舞的结果。我们从这个追踪调用获得了很多信息。后来我们发现，这是因为关卡是由许多独立立方体构成的：多重球体追踪将会返回追踪的多个命中结果，但是每个对象只有一个命中结果，这对于我们的第一个测试关卡来说没问题。
一旦我们尝试将这种方法用于单个静态网格体，我们从追踪中得到的命中结果就减少为一个，而且没有足够的信息。
解决问题
接下来显而易见的方法是简单地增加球体追踪数量；这包括一个沿蜘蛛的垂直轴进行的追踪，和在相对于蜘蛛的东南西北四个方向上进行的追踪。这使情况有了大幅度改善，我们获得的信息是原来的5倍之多。现在我们必须研究怎样利用这些信息。
飞毯
我想我们还没有提到这里在变量命名方面玩的一个小花样；我们使用了一种虚拟的“移动表面”（称之为飞毯再适合不过），它是从我们在追踪时收集的找到的表面数组计算出来的。被发现的表面——灰色的方块表示表面；红色的箭头显示的是该表面有多大影响。
我们对新发现的表面列表进行迭代。首先，丢弃所有不合适的面，也就是蜘蛛无法在其上行走的面（例如在蜘蛛上方的面和背对蜘蛛的面），然后对于剩下的面，根据我们认为它们应该对蜘蛛的朝向造成的影响大小赋予一个权重，再根据它们应该对蜘蛛的位置的影响大小赋予一个权重。我们尝试了用各种公式来计算这些权重；最终的一个公式是下列变量的加权总和：
其中第一个变量给了我们下图这样的曲线：
- 表面命中位置与蜘蛛的原点之间的距离，原点是按照我们为了查找表面而扫描的最大距离标准化的。
- 表面命中法线与蜘蛛的向上矢量的点乘积。
- 蜘蛛的向前矢量与指向所检测表面的命中点的方向的点乘积。
其中第一个变量给了我们下图这样的曲线：
一张图表，显示表面对蜘蛛朝向的影响如何随着距离而衰减。
通过整合第二和第三个变量，我们获得了一个复杂的3D表面，通过它我们可以将蜘蛛的旋转朝着我们认为比较重要的表面偏斜。
表面影响权重中前向偏斜的示例。
然后我们使用这个经过细化的列表的内容来计算虚拟“移动表面”的位置和朝向。
虚拟移动表面，在此图中以黄色显示。
这个虚拟移动表面并不是用作蜘蛛的位置和朝向的目标，而是作为指导来确定蜘蛛的当前参考帧。我们使用这个信息来告诉蜘蛛朝哪个方向“附着”，以及如何调整自身的朝向。
截止此时，我们有了一个很好的系统，而且对最新沙盒测试关卡的遍历效果也很好。不幸的是，我们的测试关卡缺少一个字面意义上的边缘案例。
在我们颇为棱角分明的初始测试关卡中，这运动系统在微型的山丘、山谷、悬崖和墙壁上运行良好。但是当我们开始试验美术团队创作的更有代表性的关卡几何体时，问题就开始出现了。
被我们称为“乒乓”的问题来自蜘蛛的朝向系统中的一条反馈回路，因为我们需要这套系统在遍历关卡时能够快速反应并正确地调整蜘蛛的朝向，所以我们不能过度抑制这个旋转运动。
截止此时，我们有了一个很好的系统，而且对最新沙盒测试关卡的遍历效果也很好。不幸的是，我们的测试关卡缺少一个字面意义上的边缘案例。
在我们颇为棱角分明的初始测试关卡中，这运动系统在微型的山丘、山谷、悬崖和墙壁上运行良好。但是当我们开始试验美术团队创作的更有代表性的关卡几何体时，问题就开始出现了。
被我们称为“乒乓”的问题来自蜘蛛的朝向系统中的一条反馈回路，因为我们需要这套系统在遍历关卡时能够快速反应并正确地调整蜘蛛的朝向，所以我们不能过度抑制这个旋转运动。
另一个大问题来自外角大于270度左右的情况，当蜘蛛全速移动时，它有可能飞离几何体，像一头被走鹃诱惑的郊狼一样掉进蓝色的深渊。
显然，问题在于我们当前的球体追踪集在蜘蛛冲出悬崖时没有“看到”它应该附着于其上的悬崖面。
显然，问题在于我们当前的球体追踪集在蜘蛛冲出悬崖时没有“看到”它应该附着于其上的悬崖面。
发生这种情况是因为我们在蜘蛛到达悬崖边缘时，是通过调整它的朝向来使它绕过边缘的。这种做法可以让蜘蛛的垂直跟踪发现悬崖，但是在蜘蛛快速移动的时候，就不会发生这种情况。需要更多的追踪。
在这个阶段，系统使用一个相对于蜘蛛的定向矢量表，要对现有系统添加附加的追踪，就需要对这个数组中每个条目添加一个附加的矢量。这解决了我们遇到乒乓问题的最初测试案例，但是QA很快就发现了另一个问题。
稍加改进
最终通过执行那些附加追踪，这两个问题都得到了解决，不过我们并不是一蹴而就地做出最终系统的，和往常一样，这是个迭代的过程。在这个阶段，系统使用一个相对于蜘蛛的定向矢量表，要对现有系统添加附加的追踪，就需要对这个数组中每个条目添加一个附加的矢量。这解决了我们遇到乒乓问题的最初测试案例，但是QA很快就发现了另一个问题。
执行了对追踪的可视化；红色轨迹表示与场景几何体的交叉。
通过创建在蜘蛛身下交汇的追踪，我们似乎已经解决了这个问题。但是添加这些附加的追踪也突出了一个问题，就是这套系统更新起来很不方便。对追踪的形状进行任何更改都需要花费很多人力，而且要求我们计算所追踪的每个方向的个别矢量。也就是说，需要进行优化，使整个更新过程大幅度精简。
对这些代码进行的小幅度重构让我们得以通过一个相连矢量的数组执行多个跟踪，这意味着我们能够有效跟踪曲线了，在此基础上又增加一些代码之后，我们就能够围绕蜘蛛对各个跟踪进行360度旋转扫描了。
对这些代码进行的小幅度重构让我们得以通过一个相连矢量的数组执行多个跟踪，这意味着我们能够有效跟踪曲线了，在此基础上又增加一些代码之后，我们就能够围绕蜘蛛对各个跟踪进行360度旋转扫描了。
跟踪的升级，从左到右：执行1个、4个和8个跟踪。
放入缓存
实践表明，场景中的这么多跟踪还是不能完全解决我们的乒乓式旋转振荡问题。它们显著减少了，但是依然存在，而且依然明显。根本的原因是这条反馈回路：
蜘蛛朝向逻辑反馈回路。
因为我们要求蜘蛛的朝向灵敏响应表面几何体的变化，所以我们不能再提高对蜘蛛旋转的抑制水平了。
既然无法通过这条反馈回路放慢进程，我们的解决方案就是在问题最明显的时候，也就是蜘蛛静止不动的时候断开这条回路。
下面示意图中的红色箭头指示了我们断开回路的位置。
既然无法通过这条反馈回路放慢进程，我们的解决方案就是在问题最明显的时候，也就是蜘蛛静止不动的时候断开这条回路。
下面示意图中的红色箭头指示了我们断开回路的位置。
此时已中断的蜘蛛朝向逻辑反馈回路。
为了做到这一点，我们缓存了探测到的表面。这些缓存会一直保持有效，直到蜘蛛的移动超过一定的距离，或者旋转幅度超出指定量，或者缓存的某个表面发生移动为止。当发生这些情况时，我们就清除缓存，重新开始。
这最终解决了我们看到的问题，而且带来了一个令人高兴的副作用，就是大大减少了在一段时间中执行的扫描量。
所以，当被要求给角色的能力添加一些与物理相关的要素（为了提高游戏性）时，我们就面临两种选择：
或
我们选择了后者。
促使我们做出这个决定的主要因素是我们的项目一开始就有的蜘蛛角色。
那个蜘蛛是用蓝图编写的，是从原先的内部Sumo Digital游戏创作赛会原型发展起来的。它是基于一个物理对象构建的，所有的移动、旋转和表面吸附都是通过对该角色添加各种力来实现的。每个用过它的人都认为，要在准确符合物理定律的模拟和有趣而迷人的游戏性之间取得平衡很困难。
这对我们来说可不好。我们必须有一套易于调整和平衡的系统，所以我们选择了第二个选项。
设计部门要求我们利用虚幻引擎中的物理材质进行扩展，具体说来就是模拟摩擦的方式。
因为我们已经在蜘蛛身上做我们自己的物理模拟了，所以在此范畴中扩展摩擦计算来支持设计部门所要求的粘滞表面效果相当容易。
我们接到的第二个请求是支持我们自定义的游戏中风力系统。
开发这个自定义风力系统是为了让我们能够吹动关卡中的游戏性对象，我们也需要让蜘蛛对这个系统做出同样的反应。要用这套系统来移动蜘蛛，只需要给代码增加一些简单的内容，我们已经对蜘蛛添加了AddForce和AddImpulse函数的实现，所以只要把它们关联一下就好。
但这个过程并不是一帆风顺的，事实证明，要让这个系统在各种帧率下保持一致，比我们预料的要难得多。
这个系统在我们的开发PC上以很高的帧率运行时表现良好。但是，把它放到我们支持的低端设备上时，就是另一回事了。
如果我们只对蜘蛛应用风力，那么这不一定会成为问题，但是我们还要使用同样的系统移动各种游戏性对象，而在这套系统下，两者的行为不一致。
我们花了不少时间调试和优化我们自己的物理模拟，最终在其中实现了物理分步。最后添加的这部分代码让我们得到了需要的一致结果。
说到将来可能要做的工作，我们就想到了两个功能：
动画是虚幻引擎的一个积极发展的方面，有一些有趣的新技术，值得我们在今后的工作中去研究。我们已经提到过试验性的可编脚本骨架绑定系统Control Rig，它可能是以更模块化、功效更强大的方式重新实现IK逻辑的好选择。惯性混合可以提供性能和混合质量方面的增益。用来检查游戏性状态和实时动画行为的新分析工具Animation Insights似乎对开发很有用。这里还有许多功能可以为未来的改进提供途径。
在我们动画系统的未来迭代方面，我们将考虑改进生成的样条的时间稳定性，以减少当跟踪在不同帧中返回的结果差异很大时出现腿脚闪烁的几率。我们的动画混合行为也还有改进的余地，目标是避免不同姿势之间过快混合，例如在蜘蛛从跑动中停下时。
我们希望了解我们的《Spyder》开发过程能让你感受到乐趣，如果你想和Agent 8一起拯救世界，那就去玩玩Apple Arcade上的《Spyder》吧！
这最终解决了我们看到的问题，而且带来了一个令人高兴的副作用，就是大大减少了在一段时间中执行的扫描量。
还是不启用物理吧
我们把浮动Pawn移动采样代码作为蜘蛛移动系统的基础，这表明我们很想做出一个符合动力学的角色。原先的游戏设计并不要求制作任何与物理相关的效果，重力始终指向角色行走的表面。所以，当被要求给角色的能力添加一些与物理相关的要素（为了提高游戏性）时，我们就面临两种选择：
- 在主角身上启用物理系统，把所有运动代码都转换为使用各种力。
或
- 用更有利于游戏性的方式模拟我们所需要的力。
我们选择了后者。
促使我们做出这个决定的主要因素是我们的项目一开始就有的蜘蛛角色。
那个蜘蛛是用蓝图编写的，是从原先的内部Sumo Digital游戏创作赛会原型发展起来的。它是基于一个物理对象构建的，所有的移动、旋转和表面吸附都是通过对该角色添加各种力来实现的。每个用过它的人都认为，要在准确符合物理定律的模拟和有趣而迷人的游戏性之间取得平衡很困难。
这对我们来说可不好。我们必须有一套易于调整和平衡的系统，所以我们选择了第二个选项。
把猫头鹰画全
前面已经提到，我们需要给蜘蛛增加一些附加的能力。设计部门要求我们利用虚幻引擎中的物理材质进行扩展，具体说来就是模拟摩擦的方式。
因为我们已经在蜘蛛身上做我们自己的物理模拟了，所以在此范畴中扩展摩擦计算来支持设计部门所要求的粘滞表面效果相当容易。
我们接到的第二个请求是支持我们自定义的游戏中风力系统。
开发这个自定义风力系统是为了让我们能够吹动关卡中的游戏性对象，我们也需要让蜘蛛对这个系统做出同样的反应。要用这套系统来移动蜘蛛，只需要给代码增加一些简单的内容，我们已经对蜘蛛添加了AddForce和AddImpulse函数的实现，所以只要把它们关联一下就好。
但这个过程并不是一帆风顺的，事实证明，要让这个系统在各种帧率下保持一致，比我们预料的要难得多。
这个系统在我们的开发PC上以很高的帧率运行时表现良好。但是，把它放到我们支持的低端设备上时，就是另一回事了。
如果我们只对蜘蛛应用风力，那么这不一定会成为问题，但是我们还要使用同样的系统移动各种游戏性对象，而在这套系统下，两者的行为不一致。
我们花了不少时间调试和优化我们自己的物理模拟，最终在其中实现了物理分步。最后添加的这部分代码让我们得到了需要的一致结果。
后续工作
随着《Spyder》发售，代码团队也有机会来反思开发历程，整理积累的知识，并思考尚未解决的问题。说到将来可能要做的工作，我们就想到了两个功能：
- 让小蜘蛛成为物理对象。
- 这将会更符合虚幻引擎的框架。通过这一措施，我们可以对我们的设计师赋能（他们纯粹使用蓝图工作），使他们能够更自由地使用当前虚幻引擎的现成功能设计原型。
- 这种粘性运动技术的其他使用。
- 《Wipeout》式的悬浮竞速。
- 《超级马里奥银河》式的平台跳跃。
- 《旺达与巨像》的游戏玩法。
动画是虚幻引擎的一个积极发展的方面，有一些有趣的新技术，值得我们在今后的工作中去研究。我们已经提到过试验性的可编脚本骨架绑定系统Control Rig，它可能是以更模块化、功效更强大的方式重新实现IK逻辑的好选择。惯性混合可以提供性能和混合质量方面的增益。用来检查游戏性状态和实时动画行为的新分析工具Animation Insights似乎对开发很有用。这里还有许多功能可以为未来的改进提供途径。
在我们动画系统的未来迭代方面，我们将考虑改进生成的样条的时间稳定性，以减少当跟踪在不同帧中返回的结果差异很大时出现腿脚闪烁的几率。我们的动画混合行为也还有改进的余地，目标是避免不同姿势之间过快混合，例如在蜘蛛从跑动中停下时。
我们希望了解我们的《Spyder》开发过程能让你感受到乐趣，如果你想和Agent 8一起拯救世界，那就去玩玩Apple Arcade上的《Spyder》吧！
立即获取虚幻引擎！
获取全球最开放、最先进的创作工具。
虚幻引擎包罗万象，并提供完整的源代码访问权限，开箱即用，诚意十足。
虚幻引擎包罗万象，并提供完整的源代码访问权限，开箱即用，诚意十足。