当我们在开始开发王牌英雄的机器人时 我们开始了最复杂的部分:怎样去做寻路？ 当人们谈到寻路的时候 通常会想到 A*寻路. 这众所周知的标准算法的确能解决寻路问题 例如RTS类的游戏就是这种解决方案 他能产生出一个容易遍历的路径. 但是当在平台游戏中在找到路径后更复杂的一步是 执行这个路径, 王牌英雄有很多不同的平台物理相关的特征。例如跳跃 双跳 起飞 漂移 跳上跳下平板 空中移动控制.我们能升级我们的单位的跳跃高度 AI需要知道他什么时候起跳 跳跃多长时间 这的确是一个巨大的挑战.
有这么多移动相关微妙的地方.我首先想到是用行为树并不能解决所有问题，行为树能很好的进行决策,但并不能解决移动中细微的控制. 更加糟糕的是 ,为了性能考虑AI们只能每秒执行10次行为树.和我预期的一样麻烦.
我想出的解决方案是记录真实玩家的移动路径 记录不只是玩家的位置还包括确切的按钮，我认为我们可以得到足够的信息来复制真正的运动与精确的控制.玩家的移动将被分割成小的片段,从一个平台到另一个平台.游戏可以将这些拼接在一起，以产生从A到B特定的路径。
用这种方式移动，行为树可以选择他想去哪和执行哪些块，这些是全自动的，非常像运动员的回放视频,行为树当然可以在任何时候停止移动并进入战斗,这将再次回到行为树的控制.
虽然上面听起来是很有趣并且可行的，但是魔鬼在细节之中.我们需要写记录和回放的代码.并且需要一个复杂的算法来分析运动记录并且把他们转化成段.并且这还不是所有. 在王牌英雄中有6个角色，每个角色都有自己的运动特性.他们可以升级走的更快，跳的更高。在场景中还有一些移动的平台，这意味着有些跳跃在特定时间内才是有效的。所有这些变化都增加了所需的算法的复杂性，和所需移动记录样本的量，才能使他工作。而且需要一种方式来使段在一起播放，使动量不能瞬间失去。 最后的问题是关卡在开发过程中还会不停的变化。每次变化都意味着需要重新记录和处理数据. 这么多问题凑在一起促使这个解决方案太麻烦并且需要太多的工作量了。虽然我仍然可以想象他可以工作的更好但是这不是一个小的独立团队的工作范围。我们需要一个更简单的解决方案，而不是这样的东西。 我们开始尝试寻找一个更好的解决方案。Bart Knuiman在Ronimo实习，他当时的实习工作是AI，所有他开始尝试这个。他创建了一个小关卡，但是他根本不需要寻路因为这上面根本没有墙和缝隙。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
