【GameLook专稿，未经授权不得转载！】

GameLook报道/作为互动艺术形式，游戏里的互动效果会直接影响玩家体验，出色的动作匹配会让玩家身临其境，但如果互动效果与玩家操作不同步，就很容易让玩家弃坑。

在此前的GDC演讲中，EA高级软件工程师Henry Allen介绍了该公司的N-teract运动匹配系统，以及如何给Madden、FIFA以及更多大作设计环境和动态匹配效果。

以下是Gamelook听译的演讲内容：

Henry Allen：

我是Henry Allen，在EA寒霜动画团队担任高级软件工程师，今天的目的是分享EA的一些多角色互动的发展，其中有些方法可能会在其他游戏和引擎中也能被用到。

首先我们会快速了解EA的角色互动系统，由于之前GDC活动中讲过这个系统，所以我们对此只做简短的介绍，随后我们会进入今天的主要内容，围绕两个话题进行，第一，多角色互动系统的拓展，不仅与其他角色互动，还会与游戏环境以及游戏内的其他物体互动，以这样的踢腿动作举例。

随后我们会谈到运动与姿势匹配，会了解我们角色系统里的两种集成运动匹配技术，与右边的图片有些关系。

N-teract是互动场景系统的缩写，也就是EA的多角色互动系统，用来探测多角色互动环境，然后与动画匹配、并在游戏里创造多人玩家互动时刻，在游戏里，它们就是这些实时互动。

比如，所有的防守都处理了玩家的所有互动，我们的多角色互动系统负责侦测玩家动画来决定什么时候哪个规则应该生效。

那么，这个系统是怎么运作的？首先，游戏动画状态机决定系统会考虑哪个选手，同时应答请求互动，并执行快速互动。游戏创作者对于这样的互动什么时候发生、会不会发生，都有着完全的控制权。

互动鉴别器（Interaction Evaluator）是中央处理器，它收集所有请求，并且把同一类型的角色互动请求分为一组，在每个组中，它首先会考虑Master选手作为互动参照，在我们的案例中，运球的人就是Master选手。

评估了Master选手之后，我们随后进行广泛核对，快速在我们的数据库中排除距离比较远的球员，然后确认合适的规则和剩余的球员。最后我们在动画数据库搜索是否有匹配的动画。

如果找到了匹配的动画，状态机就开始播放这个动画，并开始进入处理状态，来调整动画让它与角色互动一致。

物体与环境互动

我们解决了动画与互动的协同问题，但该如何将物体与环境互动加入到这个系统之中呢？为此，我们需要讨论再次互动中的被动参与者，我们将其称之为幽灵互动。

在这个互动当中，我们有两个角色与中间的受害者互动，中间这个角色没有主动参与两个互动当中的任何一个，他是一个被动参与者，在被击倒之后，没有参与后续的互动，但第一个到来的角色被另一个主动参与者击倒，这些都是由玩家或者AI控制，这对于环境互动是有意义的。

这个系统可以用在实时互动之中，一个角色可以完全不参与任何互动，而不是作为一个参照点，这个“影子”由运球者触发，并且会对其运动作出互动，这是典型的上下文环境互动，被动参与者的互动完全受到其他角色的影响。

由于其他角色只是为被动参与者提供上下文环境，从技术上来说，这个被动角色需要成为另一个角色，匹配这个角色应该比其他角色的配对更简单。

Runtime是非常直观的，我们用来匹配角色的参数有好几个，但我们不希望这些环境使用角色，所以我们决定在游戏世界里增加Locators，后者就是带有我们需要参数的互动点。

另外，我们也不希望角色和Locator有特殊代码，所以我们增加了一个新的界面处理这类角色的匹配，并将其更新到所有需要与之互动的情况。

其它工具是因果控制器，我们需要追踪locator，你可以对其进行自定义，并作为在场景中对它进行定位，并确定对应的互动与动画，我们还在数据库更新了代码来匹配这些情况。

这是我们早期角色互动的一个创意原型，我们创作了一些动画与墙壁互动，以便决定角色的手放在什么地方可以触发互动，然后我们用locator来代表墙壁在世界中的位置，角色可以利用这些locator重新与墙壁互动。

你还可以用它做更简单的互动，比如角色触摸墙上的纹理、或者玩家角色撞到了墙壁，你可以让他们用手推墙壁，而不是脸直接撞上去；或者，还可以做不同角度、风格与门把手的互动，甚至是不同的角色类型。亦或者，你还可以做角色与宝箱的互动，或者与家具等任何物体的互动。

我们还允许内容创作者识别这些locator，以支持更为复杂的互动，这意味着我们的游戏系统承载了他们需要用到的逻辑信息。

说到更复杂的互动，这是Madden游戏里的一个场景，红色的locator代表了角色第一次跌倒的位置。在游戏里，当一个犯规行动在某条线发生的时候，你可以用这条线上的locator匹配对应的动画。

在这种情况下，当角色走近locator的时候，就可以触发对应的动画，呈现合适的多角色互动。在实时游戏中，它们只是作为互动的参照点。

那么，这些locator能够与运动中的物体互动吗？最大的问题是弹道弧，因为你不能改变locator的位置去适应运动的物体，这样会看起来不自然，所以与之互动的角色需要移动。但你也不能将它当前位置匹配，因为角色离开原来的位置在追逐球的运动方向，他们需要保持一致，所以我们需要预测运动以确定未来的位置。

我们将运动物体未来的位置增加多个locator怎么样？这样随着时间的变化，系统就可以自动选择角色与不同位置之间的互动。

比如Madden团队在这里预测了足球可能运动的位置，每个点都代表了一个系统中的locator，这样玩家就可以根据实际情况匹配并与任何一个位置互动。虽然这种方法可能看起来非常简单和直观，但我们发现它非常好用。

运动匹配与互动

如果你对此不熟悉，动态匹配是一种动画技巧，给出一条通道让角色照着走，我们越来越多的动画团队开始依赖这个技术，它可以在不牺牲玩家控制的情况下做到高保真度的动画，在多角色情况下，我们也同样需要这样的能力。

在Madden游戏里，我们让动态与拉力系统匹配以实现恰当的互动。

比如这种情况下，角色之间的距离太远没办法断球，系统可以预测未来的互动，并提前选择可能发生的互动，并且把有意向参与互动的角色引导至理想的位置。

这里蓝色路线是运球者的预测路线，灰色路线是抢球运动员的路线，如果两者的路线有了交集，我们会找到与这种情况对应的互动，然后用动态匹配将防守者带到理想的位置，以便动画不需要任何的延迟就能呈现。

这种情况下，它可以适配多种防御情况，能够适应不同角度的互动，因为参与者在使用动态匹配提前预测，在互动和动画开始之前就达到了最理想的位置。

不过，这只是单个角色的动态匹配，在多角色情况下如何实现？

这个技术实际上在EA最初的8人团队就已经开始研究了，他们调整了运动匹配技术以检查不同姿势下的运动匹配质量，以便让玩家在不同参照点得到最佳的动态效果，然后让这个参照点可以被另一个角色使用，这样就可以在多角色场景下使用。

这是最早的创意动画，展示了两个角色对打和对打反映的动画，甚至做了非常具有吸引力的demo，比如两个角色通过游戏代码匹配。然而他们很快遇到了多玩家匹配的问题，并且很多年都没解决。

比如多种可能的情况下，你如何挑选参与的合作者？或者在有效距离之外的参与者怎么办？如何处理被动或者幽灵参与者？比如被击打者如果有更恰当的运动，就会让整个互动显得更自然。

经过多年的尝试之后，很明显的是，如果将多角色互动匹配与现有的角色运动系统分开研发，会是对资源的浪费。我们意识到团队需要一起努力解决这个问题，我们有两个强大的系统，但如何让他们一起工作呢？

由于运动匹配支持了多角色，他们都在通过参照角色做匹配，并且都是通过动画数据库驱动。所以我们一开始是用后匹配数据库取代最初的场景数据库，这也是行之有效的，但并没有发挥两个系统的潜力。

我们得到了需要的效果，但丢失了相当多的功能。

为此，我们回到了原点，以寻求不同的方法。

一个可能的选项是将两个数据库合并起来，但问题在于两个数据库的功能差别很大，对于运动匹配，每一个与功能的匹配都是基于它与原始动画的匹配度多高，如果任何一个失败，我们都会拒绝匹配。

两个功能在各自问题解决方面都有不错的效果，所以我们觉得不需要改变任何一个。

因此，我们保持了两个系统不便，但如果遇到多角色动画，我们将其发送到运动匹配数据库以寻找解决方案，为同一个动画找到了多个进入点。

比如，这里20帧当中每4帧就有一个进入点，下面这张图是为每个进入点匹配的数据库，被选择的资源在左侧，被选择条件在右边。比如我们可以将地16帧与起始帧匹配在一起。

这样做可以让我们保留两种数据库，使用选定功能并保持匹配风格，我们希望通过互动、匹配和拒绝一些帧数，我们的服务器可以做到宽相匹配、限制需要检查的帧数，解决一些规模化性能方面的担忧。

前面提到的两个角色击打被动角色的案例，也使用了运动匹配，一开始的时候，系统选择让第一个互动者从正面击打受害者，但由于时延的问题，后者被击打的时候刚好转过身去，这时候运动匹配就不合适了，虽然出发了新的动画，但在连贯性方面表现的很差。

经过了调整之后，我们选择了从背后击打，并匹配了更自然的动画，这有了更好的表现，而且不用完全改变被动参与者的前后面。

需要澄清的是，我们最初选择让这帧图片出现在互动中，因为当时设计的角色互动是彼此面对面的，然而当真正相遇的时候，影子参与者转过了身，所以这里的交互点失败，触发了新的匹配，选择了从背后击打。

后来的互动效果更加自然，当然，如果能够彻底改变动画，两个角色的手脚互动会更好一些。这就说到了我们的下一个话题，连贯性选择。

传统的互动包括动画的选择与播放，如果有时候两个角色互动变成了三个角色碰撞，运动匹配的一个作用就是按照需要把数据库里的任何一帧切换成其他数据库里的任意帧，以做到向玩家呈现互动的连贯性。

比如这里绿色的路径是预设路线，蓝色的路线是实时更新的动画匹配。

我们增加了多个功能和选择，我们最后增加到了互动系统之中以映射运动匹配中可用的功能，以便让两个系统尽可能高效率协同，这只是首个类似的改变。

遇到的挑战

不意外的是，这样的设计也存在一些挑战，我没时间一条条细说，但这里会谈到一些。

首先是不稳定的选择，当FIFA最初做的时候，我们觉得非常不稳定，超过一帧或者两帧就很难选择同一个动画，本应该根据需要来选择对应的动画，但这个方法并不总是能做到。其中一个很大的原因就是存在不同的匹配风格，尤其是互动当中比较复杂的匹配请求，主要是对于每个进入点，因为任何条件不满足或者特定帧没能匹配，都会完全改变运动匹配对这一帧的匹配选择。

我们解决这个问题主要的方法是拓展动画匹配的容忍度，换句话说，选定了互动之后，我们能够选择的匹配范围应该更大，这让运动匹配更稳定。

我们面临的另一个比较大的问题是Pathing的处理，通常来说支持动画协同的互动会在互动的时候发出指令，也就是使用Root motion。

如动画所示，我们觉得这个方法比较有前途，但真正使用Root motion协同互动的时候，就夺走了玩家对角色的控制权，严重影响了玩法。

比如蓝色的玩家控制路径从来没有和绿色应该有的路线重合，这对于FIFA来说是破坏游戏体验的，幸运的是，FIFA研发引擎让我们有更多的选择，我们可以只需要改变动画而去改变Pathing。

我们做了这样的尝试，认为虽然会有一些不协调，但不会如此明显。因为本质上来说，这是为了做运动匹配，而不是精准的动作协同。

性能也是我们关注的点，FIFA有很多的数据和系统，所以说说我们做的一些优化。我们很快发现这样的互动系统在传统互动场景下会有很多帧的静态图形。

比如这个非常极端的情况下，两个角色的互动动画实际上没有多大的变化。

默认情况下，我们每4帧就有一个进入点，所以在300多帧动画里，我们加入了75个进入点，这时候我们可以改为每8帧一个点，但整体上会让互动不那么精准，因为不同的帧之间共享一些匹配条件。

不过，这个动画里的很多匹配条件是相同的，因为角色动作和角度很大程度上是静态的，最终我们的选择是，从75个进入点，减少为4个进入点，也让运动匹配需要处理的数据库大幅减少，对性能提升很显著。

我想提到的另一个优化是Path Matching，解决方法是在互动系统中增加更多的匹配项，让运动匹配系统中的Path Matching更有效率，也进一步减少了发送到运动匹配中的帧数。

比如，假设绿色箭头是游戏里需要的路径，动态路径会按照红色箭头走就很糟糕，因为它会在未来走到错的方向上，互动没有未来的匹配概念，所以我们增加了远距离匹配条件，这增加了很多的动画，导致动作匹配的表现不佳。

需要注意的是，如果增加互动规模，会答复增加动画的覆盖率，如果互动角色更多，可能会指数级增长。

不过，对于2-3个角色互动而言这是很好用的，你可以像我们那样做continuous requery pose matching，或者选择更好的起始帧，我认为还可以用到只需要给少两角色做pose matching的多人互动之中。

我们可以从动画里看到，这些互动的呈现是在保证玩法为前提的情况下牺牲了一些动作协调性，我认为未来可以在这方面做出提高，比如通过Root motion和精准协同以得到更高的保真度视觉效果。不过，我们队目前的效果非常满意，并希望将它用到更多的游戏之中，以上就是我分享的全部内容。