游戏中有哪些看上去很简单，但实际上需要极高技术力或是极高成本的细节？

我说一个简单的：角色怎么样自然地走路？
& c: C6 [: V# T& \& m8 K/ a4 H; _6 D在Motion Matching这个技术发展成熟之前，我们大部分的游戏中角色动作都是由状态机决定的，什么叫状态机呢？状态机就是我们预先定义了一些节点作为状态，比如跑，跳，下蹲，发呆。当我们传进用户输入的时候（比如按下了跑的按钮），那么角色将从一个状态转移到另一个状态，这个输入称为状态转移函数，也就是我们预定的一些规则，比如当角色在发呆的时候，按下跑的按钮，角色就转换为奔跑的状态。这张图是一个简单的角色移动的动画状态机：
4 x; R8 P& O/ A; k# _% N

看起来似乎还不错也挺简单的对吧？那么问题在哪里呢？
" p4 b, f6 O: \  j/ k" {0 k+ U第一，当角色动画从一个状态转移到另一个状态的时候，怎么样产生一个平滑自然的动作过度？传统的状态机方法，往往是在当前状态到目标动作间，创建一个简单粗暴的线性插值，又或者直接停止当前动画的片段播放，转而播放目标动作的动画片段。这两种方法都会产生一个问题：角色动作非常生硬。比如角色上一秒正在向前奔跑，玩家突然按下了后退键，这时候角色应该如何行动？真实世界中的人可能会先伸出一只脚刹停，然后转身，再反向发力奔跑。但是如果使用动画状态机，往往角色的动作并没有这个过度，而是一瞬间从向前跑变成了向后跑的姿势，这就是角色动作中不自然的地方，玩家或许说不上来为什么，但是他们感觉得到。
9 M& N* U1 x% U' t5 L  ^第二，当角色的动画状态增加的时候怎么办？根据我们前面的描述，状态转移函数其实是人为指定的规则，当状态增加时，也就意味这新的规则需要被传入，比如我们自然而然的知道，人跳在空中的时候，是不能转移到奔跑状态的，而是要先落地，但是这些规则计算机并不知道，所以需要人为指定，假设一个游戏中，角色除了发呆，奔跑，跳跃，还有爬墙，甩绳子，开枪，拳击这些状态（通常的第一人称类游戏，往往都有不下几十个状态），那么理论上设计者需要考虑任意两个状态之间有无转换，如何转换，那么其设计的复杂度会迅速提升，于是动画师就需要浪费大量的时间用于制定这些运动规则。
, v9 Z2 f, B1 E. j9 I! i+ G育碧最早开始了motion matching的尝试，所谓motion matching，其核心思想是，不再人为指定角色动作之间的转换，而是单纯地指定目标动作，而从当前动作到目标动作之间的插帧，则由计算机从动作数据库中自动找出一个最佳匹配，或者根据已有的动作数据，基于插值生成一个新的，最合理的动作。那么如何衡量一个动作的合理性呢？这里我们可以引入非常多的“约束”，这个“约束”可能是基于用户的输入（比如按向后跑的键，强制要求角色掉头）；可能是角色当前的速度、加速度；可能是角色的IK（反向动力学）数据（比如一个角色正在上楼，下一个动作脚尖必须贴在楼梯地面上）；可能是物理引擎的碰撞检测反馈（比如下一秒角色碰到了一个比较矮的栏杆，必须低头才能通过）。
如果我们把角色身上所有骨骼最终的位置、朝向看作一系列的变量，上面提到的约束看作是这些变量组成的等式或不等式，将基于动捕录制好的所有动作张成的线性空间看作这个约束的解空间，那么这个问题就变成了对于有限个变量和约束条件，在解空间内搜索最佳解的问题。于是动画师们基于经验去指定规则的方案，就变成了一个纯粹的数学物理问题。
我们来看看基于motion matching这一思想实现的角色动作：


即使是怎么走路这么简单的问题，为了解决好也仍然需要大量的努力。所以真正了不起的技术往往都藏在这些不起眼的细节中。
7 V. [+ _, n0 r/ z  [- J=================================================
4 t1 b# D8 I6 b0 z- }3 H. n补充一篇今年Siggraph 2020的新paper[1]，仍然由育碧带来。这次育碧尝试了把神经网络和传统Motion Matching方案结合起来，在Motion Matching的基础框架下，把其中某些步骤的计算（需要消耗大量内存和计算量的）通过trained NN kernel来替换。这样既保证了学习的启发性（大量减少训练时长，同时保证结果的可预测性），又能够加速运行时的速度，减少存储开销。
- ~3 e9 X  Q. W  U7 N& F4 f4 i

" p0 t3 p3 u7 f1 w, o具体视频效果看这里：
参考
' d* B8 f; u1 u) Z/ G$ I

• ^LEARNED MOTION MATCHING https://montreal.ubisoft.com/en/learned-motion-matching-2/