大量游戏中使用的人工智能概念

介绍

本文将介绍大量游戏中使用的人工智能概念，你将会了解解决AI问题有哪些可用的工具，它们是如何一起工作的，以及你将如何在所选语言或引擎中实施这些工具。

本文需要你对游戏有基本的理解，同时掌握一些数学概念，例如几何、三角函数等等。其中举出的代码例子都是虚拟代码，所以不用具备特别的编程语言水平。

什么是游戏AI

游戏AI主要解决的是游戏人物根据当前条件应该做出哪些动作。传统AI环境中所指的智能体通常是游戏中的人，但现在也可以指一辆车、机器人或更抽象的，例如一群目标对象、一个国家或人口。它们都需要观察周围的环境，并基于环境做出决定、执行动作。通常这一过程是感知/思考/行动的循环。

感知（Sense）：智能体检测或被告知环境中有可能会影响其动作的物体（附近有危险、要捡的物品、需要查看的地点）

思考（Think）：智能体要想出应对方法（比如要选择一个安全的时机捡东西，或者决定是先攻击还是隐藏）

行动（Act）：智能体将之前的决策付诸行动（例如开始向敌人或目标物体移动）

环境变化，在新数据下重复这一循环……

在现实AI问题中，大部分公司重点关注的是“感知”这一环节。例如，自动驾驶汽车必须给前方道路拍照，并将其与雷达或LIDAR数据进行对比，之后尝试解读它们看到了什么。这通常由机器学习方法来完成。

游戏却不同，因为它们不需要复杂的系统来提取信息，因为大部分信息都在模拟系统内部。我们不需要运行图片识别算法来发现敌人的位置；游戏知道敌人在哪，可以直接将信息反馈给决策过程。所以游戏中的“感知”环节比较简单，难的是后两步。

游戏AI的发展限制

游戏中的AI通常会面临以下几种限制：

通常不会像机器学习算法那样“预训练”；写一个神经网络观察上千名玩家并学习是不现实的，因为这种方法在游戏还未发布的时候根本无法进行。

游戏应该提供趣味性和挑战性，而不是追求“最优”。所以即使智能体的水平能超过人类，也不会是设计师追求的目的。

智能体还不能太“机械”，要让对手真的认为他的队友是“人”而不是“机器”。AlphaGo虽然厉害，但与之交手的选手们都觉得它下棋的方法很不寻常，感觉像和外星人对战。所以游戏AI也要调整得更“拟人化”一些。

要支持实时处理，算法不能长时间占用GPU就为了想出对策。10毫秒已经过长了。

理想的系统是数据驱动而不是硬编码，这样即使不会编程的人也能做出调整。

有了这些原则，我们可以开始看看在感知、思考、行动循环中所使用的简单AI方法了。

基本决策制定

让我们以简单的游戏《乓》为例，要保证乒乓球可以弹到球拍上，如果掉落就算输了。AI的任务就是决定球拍的移动方向。

硬编码条件语句

如果我们相用AI控制球拍，那么最直接最简单的方法就是尝试让球拍一直位于乒乓球的下方。当球接触球拍后，球拍的位置就是合适的。

用虚拟代码表示：

every frame/update while the game is running:

if the ball is to the left of the paddle:

move the paddle left

else if the ball is to the right of the paddle:

move the paddle right

这种方法太简单了，但是在代码中：

“感知”部分有两个“if”语句。游戏知道球和球拍的位置，所以AI询问游戏二者的位置，从而感知到球的运动方向。

“思考”部分同样在两个“if”语句之中。它包含了两个决策，最终会决定向左、向右或不移动球拍。

“行动”表现在代码中就是向左或向右移动。但是在其他与戏中可能包括移动的速度。

我们将这种方法称为“reactive”，因为规则很简单。

决策树

乒乓球游戏也可以用决策树模型进行可视化：

第一眼看去，你可能觉得决策树和if语句没什么区别。但是这个系统中，每个决策都包括一个精确的条件和两种可能的输出，可以让开发者不用硬编码就能从代表决策树的数据中搭建AI。用简单的表格来描绘决策树是这样的：

如果样本很多，决策树真的非常强大，可以高效地进行情境分辨。

脚本撰写

设计AI的人员可以根据自己的想法安排决策树，但是他们必须依靠编程人员提供的所需条件和动作。如果我们给设计人员更好的工具，可以让他们创造自己的条件，那会怎样呢？

编程者可以将条件（判断球在球拍的左边还是右边）换成某项值，决策树的数据看起来可能像这样：

跟上面的表格相同，但是决策有它们各自的代码。更进一步，将这样的表达方式（用脚本语言而不是数据）带入逻辑结论也是可能并且常见的。

对事件做出反应

以上的乒乓游戏中，核心思想就是不断运行三步循环，并根据上一步的环境状态采取行动。但是在更复杂的游戏中，与评估各项条件相比，更多的是对情况做出反应，这在游戏场景的变换中是很常见的。

比如在一项射击游戏中，敌人首先是静止的，一旦他们发现了玩家，不同角色的敌人就会采取不同行动。冲锋兵可能会向玩家攻击，狙击手会位于后方准备射击。这也是基本的应对系统，但是它需要更高级的决策过程。

高级决策制定

有时，我们想根据智能体目前的状态做出不同的决策，对决策树或脚本来说，条件过多时就无法高效地运行。有时，我们要提前思考并估计环境会如何变化，所以就需要更复杂的剞劂方法。

有限状态机（Finite state machine）

一个有限状态机（FSM）指的是某个物体，例如AI智能体，目前处在某个状态中，之后会转移到另一个状态中。由于状态的总数是有限的，所以称为“有限状态机”。现实中此类例子是红绿灯。

在游戏中，让卫兵巡逻、攻击或逃跑等动作可以用简单的if语句表示。但是如果加上状态，例如游荡、搜查、跑步寻求救援等动作，if条件句就会变得很复杂。考虑到所有状态，我们列出了各状态之间需要的过渡状态。

用可视化图表示：

层次状态机（Hierarchical state machine）

你也许注意到上表中有些过渡状态是相同的游荡状态中的大部分过渡和巡逻中的状态相同，但最好是互相区分开。游荡和巡逻都是非战斗状态下的一部分，所以我们可以看做它的“子状态”：

主要状态

非战斗状态

可视化

行为树（behavior trees）

在决策过程中，有个小问题，即过渡原则和当前状态紧密相关。在很多游戏中，这种方法没为题，使用上述层次状态机还能减少重复。但是有时你想有一种通用的规则，不需要考虑状态。例如当智能体的健康值减少到25%，你可能想赶快逃跑。当设计师把这一数值降到10%时，你可能会改变所有相关的过渡状态。

对于这种情况，理想状态下需要一个系统，该系统决定哪些状态可以在另一些状态之外存在，以便能在一个地方正确转换。这就是行为树（behavior tree）。

部署行为树的方法有很多，但是核心思想都相同：算法开始于一个“根节点”，树中的各个节点表示决策或动作。例如前面提到的卫兵层次状态机，用行为树表示：

你可能会发现，这个树中从巡逻状态返回到游荡状态没有过度，这时就需要引入无条件的“重复”节点：

行动和导航

我们有了乒乓球拍移动和卫兵作战的例子，但是我们要怎样真正地在一段时间内让它们移动呢？如何设置速度、如何躲避障碍、设计线路等等？这一部分我们将详细讲解。

控制

从基础层面来说，我们可以认为每个智能体有自己的行动速度和方向，它们会在思考阶段计算速度和方向，在行动阶段执行。如果我们知道智能体的目的地，就可以用等式表示：

desired_travel = destination_position – agent_position

但是，在更复杂的环境中，简单的等式是处理不了的，也许速度过慢、智能体会在半路遇到障碍等。所以，有时需要考虑加入其他值，让行走动作更复杂。

找路

在网格中，如果要走到目的地，要先看看周围可以移动的网格。下图是一个简单的搜索动作案例，首先从起点开始搜索，知道找到目的地，再规划路线：

但是，这种寻找方式好像太浪费了，扩展了很久才找到最佳路线。下面这种方法在找路时，每次只选择目标坐标方向的最佳方块，从而能减少很多候选方块：

学习与适应

虽然文章开头我们提到，游戏AI不常用到机器学习，但是我们从中也可以有所借鉴，在设计类游戏或对抗类游戏中也许有用。例如在数据和概率方面，我们可以用朴素贝叶斯分类器来检查大量输入的数据，并尝试分类，让智能体对当前情况做出合适的反应。在预测方面可以用到马尔可夫模型等等。

知识表示（Knowledge representation）

我们已经讨论了做决策、计划、预测的各种方法，但是如何才能更有效地掌握整个游戏世界呢？我们应该如何收集并组织所有的信息？如何将数据转化成信息或知识？各种游戏的方法各不相同，但是有几种相同的办法可以使用。

标签

将用于搜索的碎片化信息打标签，这是最常见的方法。在代码中，标签常用字符串表示，但是如果你知道所有使用的标签，你就能将字符串转换成唯一的数字，从而节省空间，加速搜索。

智能目标

有时，标签不足以涵盖所有需要的有用信息，所以另一种存储信息的方式就是告诉AI它们的备选项，让它们根据需要选择。

回应曲线

回应曲线，简单地说就是它是一张图，输入用x轴表示，虚拟的值，例如“最近的敌人距离”和输出用Y轴表示，通常从0.0到1.0之间。该图表示了输入到输出之间的映射关系。

黑板

黑板，顾名思义，记录的是游戏中各个参与者做出的找路动作或决定，其他人也可以使用其中记录的数据。

影像力图

游戏AI经常需要考虑向哪里移动等问题，这类问题通常可以看做是“地理”问题，需要了解环境的形式和敌人的位置。我们需要一种方法将地形考虑进去，对环境有个大概了解，影像力图就是为了解决这个问题做出的数据机构。

结语

本文对游戏中使用的AI进行了大致讲解，它们的使用场景都很有用，其中的一些技术也许不常见，但是很有潜力。由于本文篇幅较长，我们并未对各项方法做详细介绍。感兴趣的同学可查阅原文。