【转】关于AI的目标导向型行动计划
作者：Brent Owens
目标导向型行动计划（简称GOAP）是一种能够轻松呈现给你的代理选择的AI系统，也是帮助你可以无需维持一个庞大且复杂的有限状态机而做出明智的决策的机器。
演示版本
在这一演示版本中存在4种角色类别，每种类别使用的工具会在使用后一段时间被弄坏：
矿工：在岩石上挖矿。需要一个工具的帮忙。
樵夫：砍树去创造原木。需要一个工具的帮忙。
伐木工：将树切割成可使用的木头。需要一个工具的帮忙。
铁匠：在铁工厂锻造工具。每个人都要使用他所创造的工具。
每种类别将能够自动识别（使用模板导向型行动计划）自己需要采取怎样的行动去实现目标。如果他们的工具坏掉了，他们将前往提供铁匠所创造的工具的供应处。
什么是GOAP？
目标导向型行动计划是代理的一种人工智能系统，让你能够计划一系列行动去满足一个特殊的模板。特殊的行动序列不仅依靠于目标，同时也依靠于世界和代理当前的状态。这意味着如果同意的模板是针对于不同的代理或世界状态，你变回获得一个完全不同的行动序列，浙江能够让AI变得更加东太后且显示。让我们着眼于一个例子，即上述演示中所看到的内容。
我们拥有一个代理，他是伐木工，将把原木砍成木柴。这时候斧头将带着MakeFirewood的目标，并具有ChopLog，GetAxe和CollectBranches的行动。
ChopLog行动将把一根原木变成木柴，但前提是伐木工人拥有一把斧头。GetAxe行动将提供给伐木工人一把斧头。最后，CollectBranches行动将创造出木柴，并且不需要斧头，但是木柴的质量将不是很高。
当我们提供给代理MakeFirewood目标时，我们将看到两种不同的行动序列：
需要木柴–>GetAxe–>ChopLog–创造出木柴
需要木柴–>CollectBranches–创造出木柴
如果代理可以获得斧头，他们便会通过砍伐原木将其变成木柴。但如果他们不能获得斧头，他们便可以选择去收集树枝。每种序列都将完成MakeFirewood这个目标。
GOAP能够基于可行的先决条件去选择最佳序列。如果手边没有斧头，那么伐木工便不得不去寻找树枝。而这么做需要花费较长时间并只能获得一些低质量的木柴，所以我们不希望这种情况一致持续下去。
GOAP是针对于谁
到目前为止你可能熟悉有限状态机（FSM），但如果你并不熟悉，那么着眼于这个教程。
关于你的一些FSM代理，你可能遇到过某种较为复杂的状态，你可能会不想要添加新行为，因为它们会在AI中引起过多副作用和缺口。
GOAP会将如下状态：
fsm_states(from gamedevelopment)
变成这样：
goap_states(from gamedevelopment)
通过减弱每个行动，现在我们可以单独专注于每个行动。这会让代码趋于模块化，变得更容易进行测试与维持。如果你想要往另一个行动添加新内容，你便可以直接做，而无需改变任何其它行动。尝试着基于一个FSM去做到这些！
同样地，你可以在运行中添加或删除行动去改变一个代理的行为从而让他们变得更加东太后。拥有一个食人魔会突然开始咆哮？那就提供给它们一个全新的“咆哮攻击”行动，并在它们平静下来时将其删除。你需要做的只是添加行动到行动列表上：GOAP计划者将负责剩下的内容。
如果你发现你的代理拥有一个非常复杂的FSM，你就应该够尝试下GOAP。你的FSM变得过于复杂的一个标志便是当所有的状态拥有大量条件语句并会测试它们接下来将变成何种状态，同时添加新的状态，这一切都会让你深深叹息。
如果你拥有一个非常简单的代理，只是执行1,2种任务的话，那么GOAP可能有点太过棘手，FSM便足够了。然而，你还是可以着眼于这里的相关理念并看看它们是否足够简单并能够应用于你的代理中。
行动
行动是代理做的事。通常情况下它只是以动画和声音呈现出来，并且会改变一些状态（游戏邦注：例如添加木柴）。打开一扇门与捡起铅笔是完全不同的行动（和动画）。行动与行动间是相互独立的，并不需要去担心其它行动是什么。
为了帮助GOAP决定我们想要使用怎样的行动，每个行动都会被赋予一个成本。在较低成本的行动中将不能选择较高成本的行动。当我们将行动排列在一起时，我们将合计成本，然后选择带有最低成本的序列。
让我们为行动分配一些成本：
GetAxe的成本：2
ChopLog的成本：4
CollectBranches的成本：8
如果我们再次着眼于行动序列并合计总成本，我们将看到最便宜的序列是：
需要木柴–>GetAxe（2）–>ChopLog（4）=创造木柴（总共是6）
需要木柴–>CollectBranches（8）=创造木柴（总共是8）
获得一把斧头并砍断原木创造木柴是基于较低成本6，而收集树枝创造木柴则是基于较高的成本8。所以我们的代理选择获得一把斧头去砍断树木。
但是是否将永远运行着同样的序列？如果我们引进先决条件的话会怎样？
先决条件和效果
行动拥有先决条件和效果。先决条件是行动运行所必须的状态，而效果则是行动运行后所发生的状态改变。
例如，ChopLog行动要求代理获得手边的斧头。如果代理并未拥有斧头，它便需要找到另外一个能够满足先决条件的行动，从而让ChopLog能够运行起来。幸运的是，GetAxe行动能够做到这点—-这是行动的效果。
GOAP计划者
GOAP计划者是段着眼于行动的先决条件和效果的代码，它将创造能够满足目标的序列。代理将朝着该目标前进，并伴随着一个世界状态以及代理能够执行的一列行动。基于这一信息，GOAP计划者能够排列行动，明确哪些是可运行的哪些不能，然后决定哪个行动是最突出的。幸运的是，我已经为你写好了这一代码，你无需再为此多花时间了。
为了进行设置，让我们添加先决条件和效果到伐木工的行动中：
GetAxe的成本：2。先决条件：“存在斧头，”“并未拥有斧头。”效果：“拥有一把斧头。”
ChopLog的成本：4。先决条件：“拥有一把斧头。”效果：“创造木柴。”
CollectBranches的成本：8。先决条件：（没有）。效果：“创造木柴。”
现在GOAP计划者拥有排列行动序列所需的信息去创造木柴（我们的目标）。
我们开始基于当前世界的状态和代理的状态执行GOAP计划者。这一组合的世界状态是：
“并未拥有斧头”
“存在斧头”
“阳光很耀眼”
着眼于我们当前可行的行动，唯一与它们相关的状态是“并未拥有斧头”和“存在斧头”状态；另外一个可能是用于使用其它行动的其它代理身上。
现在，我们拥有当前的世界状态，行动（带有自己的先决条件和效果）以及目标。让我们进行计划吧！
GOAL: “make firewood”
Current State: “doesn’t have an axe”, “an axe is available”
Can action ChopLog run?
NO – requires precondition “has an axe”
Cannot use it now, try another action.
Can action GetAxe run?
YES, preconditions “an axe is available” and “doesn’t have an axe” are true.
PUSH action onto queue, update state with action’s effect
New State
“has an axe”
Remove state “an axe is available” because we just took one.
Can action ChopLog run?
YES, precondition “has an axe” is true
PUSH action onto queue, update state with action’s effect
New State
“has an axe”, “makes firewood”
We have reached our GOAL of “makes firewood”
Action sequence: GetAxe -> ChopLog
计划者将贯穿其它行动而运行，当它发现目标的解决方法时也不会停下来。如果另外一个序列拥有较低的成本的话要怎么办？它将贯穿所有可能性去寻找最佳解决方法。
当它在计划时，它将创造一棵树。每当行动得到落实，它将离开可行行动的列表，如此我们将不具有紧紧相连的50个GetAxe行动。状态是随着行动的效果发生改变。
计划者所创造的树如下：
freemind(from gamedevelopment)
我们可以看到它会找到3种通向目标的方法：
GetAxe–>ChopLog（总成本是6）
GetAxe–>CollectBranches（总成本是10）
CollectBranches（总成本是8）
尽管GetAxe–>CollectBranches是可行的，但是最便宜的方法应该是GetAxe–>ChopLog。
先决条件和效果在代码中是怎样的？这是取决于你，但我发现将其作为键值对进行储存是最简单的，即在此键始终是一串字符，而值则是一个对象或基本类型（float，int，Boolean之类的）。在C#中是这样的：
HashSet< KeyValuePair<string,object> > preconditions;
HashSet< KeyValuePair<string,object> > effects;
当行动在执行时，这些效果是怎样的，它们将做什么？其实它们什么也不需要做—-它们只是用于计划，在真正运行前并不会对代理的状态产生影响。
这是值得强调的：计划行动与运行它们并不相同。当一个代理执行GetAxe行动时，可能在它周围就有许多工具，将播放弯腰捡东西的动画，然后再把斧头装进它的背包中。这改变了代理的状态。但是，在GOAP计划期间，状态改变只是暂时的，所以计划者可以明确最佳解决方法。
程序上的先决条件
有时候，行动需要做更多事去决定它们是否可以运行。例如，GetAxe行动拥有“存在斧头”这样的先决条件即需要去探索世界，以判断是否存在代理可以使用的斧头。它将决定最近的斧头是很遥远或者藏在敌人背后，并将传达它不能运行的信息。这一先决条件便是程序上的，并需要运行一些代码；这并不只是我们能够触发的简单的Boolean操作符。
显然，这些程序上的先决条件需要花些时间才能运行，并且将执行于渲染线程以外的内容，最理想的便是背景线程或作为Coroutines（在Unity中）。
你也将拥有程序效果，如果你希望的话。如果你想要引进更加动态化的结果模拟将能够在运行过程中改变行动成本！
GOAP和状态
我们的GOAP系统将需要呈现在一个小型的有限状态机中，因为在许多游戏中，行动需要为了执行而接近一个目标。我们最终拥有3种状态：
Idle
MoveTo
PerformAction
当出现idle时，代理将明确他们想要完成的目标。这一部分是在GOAP外部进行处理；GOAP将只是告诉你能够执行目标的行动。当选择好目标时，它将被转移到GOAP计划者中，并伴随着世界和代理的开始状态，计划者将传回一个行动列表（游戏邦注：如果它可以实现目标的话）。
当计划者完成任务而代理拥有一个行动列表时，它将尝试着执行第一个行动。所有的行动需要明确它们是否需要处在目标范围内。如果它们这么做，那么FSM将推动下一种状态：MoveTo。
MoveTo状态将告诉代理它需要移向特定的目标。代理将作出移动（播放行走的动画），然后让FSM知道它何时是处于目标的范围内。这一状态之后将被删除，从而行动将能够执行。
PerformAction状态将在GOAP计划者所传回的行动序列中运行下一个行动。行动可以是即时的或者持续好几帧，但当它完成后将离开列表，然后下一个行动便可以开始执行（再一次地，需要在一个对象范围内检查下一个行动是否需要被执行）。
这些内容将一直重复着直到不再有行动可以执行，那时候我们将回到Idle状态，获得一个新目标并再次进行计划。
真正的代码例子
是时候着眼于真正的例子了！别担心；这并不复杂，我提供了Unity和C#中的一份工作副本能够帮助你进行尝试。我将在此简单地进行阐述，从而让你可以进行探索。代码使用了之前提到的WoodChopper例子。
如果你想做的更好，先在此获得代码：http://github.com/sploreg/goap
我们拥有4种劳工：
铁匠：将铁矿石变成工具。
樵夫：使用一种工具将树砍成木头。
矿工：使用一种工具去挖矿石而创造铁矿石。
伐木工：使用一种工具将木头砍成木柴。
工具将随着时间的流逝而磨损，并需要被替换。幸运的是，铁匠能够创造工具。但他们需要铁矿石才能创造工具，这时候便需要矿工的帮忙（他同样也需要工具）。伐木工需要木头，而这些是源自樵夫；他们都需要工具。
工具和资源被储存在供应处。代理将从供应处收集他所需要的材料或工具，同时在这里放下他们所创造的产品。
代码具有6种主要的GOAP类别：
GoapAgent：了解状态并使用FSM和GoapPlanner去操作。
GoapAction：代理能够执行的行动。
GoapPlanner：计划GoapAgent的行动。
FSM：有限的状态机。
FSMState：FSM中的一种状态。
IGoap：我们的劳工演员所使用的界面。与GOAP和FSM的事件相关联。
让我们着眼于GoapAction类别，因为这是你需要划入子集的内容：
public abstract class GoapAction : MonoBehaviour {
private HashSet<KeyValuePair<string,object>> preconditions;
private HashSet<KeyValuePair<string,object>> effects;private bool inRange = false;
/* The cost of performing the action.
* Figure out a weight that suits the action.
* Changing it will affect what actions are chosen during planning.*/
public float cost = 1f;/**
* An action often has to perform on an object. This is that object. Can be null. */
public GameObject target;public GoapAction() {
preconditions = new HashSet<KeyValuePair<string, object>> ();
effects = new HashSet<KeyValuePair<string, object>> ();
}public void doReset() {
inRange = false;
target = null;
reset ();
}/**
* Reset any variables that need to be reset before planning happens again.
*/
public abstract void reset();/**
* Is the action done?
*/
public abstract bool isDone();/**
* Procedurally check if this action can run. Not all actions
* will need this, but some might.
*/
public abstract bool checkProceduralPrecondition(GameObject agent);/**
* Run the action.
* Returns True if the action performed successfully or false
* if something happened and it can no longer perform. In this case
* the action queue should clear out and the goal cannot be reached.
*/
public abstract bool perform(GameObject agent);/**
* Does this action need to be within range of a target game object?
* If not then the moveTo state will not need to run for this action.
*/
public abstract bool requiresInRange ();/**
* Are we in range of the target?
* The MoveTo state will set this and it gets reset each time this action is performed.
*/
public bool isInRange () {
return inRange;
}public void setInRange(bool inRange) {
this.inRange = inRange;
}public void addPrecondition(string key, object value) {
preconditions.Add (new KeyValuePair<string, object>(key, value) );
}public void removePrecondition(string key) {
KeyValuePair<string, object> remove = default(KeyValuePair<string,object>);
foreach (KeyValuePair<string, object> kvp in preconditions) {
if (kvp.Key.Equals (key))
remove = kvp;
}
if ( !default(KeyValuePair<string,object>).Equals(remove) )
preconditions.Remove (remove);
}public void addEffect(string key, object value) {
effects.Add (new KeyValuePair<string, object>(key, value) );
}public void removeEffect(string key) {
KeyValuePair<string, object> remove = default(KeyValuePair<string,object>);
foreach (KeyValuePair<string, object> kvp in effects) {
if (kvp.Key.Equals (key))
remove = kvp;
}
if ( !default(KeyValuePair<string,object>).Equals(remove) )
effects.Remove (remove);
}public HashSet<KeyValuePair<string, object>> Preconditions {
get {
return preconditions;
}
}public HashSet<KeyValuePair<string, object>> Effects {
get {
return effects;
}
}
}
这里没什么特别的内容：它储存了先决条件和效果。它同样也知道它是否必须处于目标范围内，如果这样的话，FSM便知道在需要的时候推动MoveTo状态。它也知道它是何时完成的；这是由执行行动类别所决定。
以下是其中的一种行动：
public class MineOreAction : GoapAction
{
private bool mined = false;
private IronRockComponent targetRock; // where we get the ore fromprivate float startTime = 0;
public float miningDuration = 2; // secondspublic MineOreAction () {
addPrecondition (“hasTool”, true); // we need a tool to do this
addPrecondition (“hasOre”, false); // if we have ore we don’t want more
addEffect (“hasOre”, true);
}public override void reset ()
{
mined = false;
targetRock = null;
startTime = 0;
}public override bool isDone ()
{
return mined;
}public override bool requiresInRange ()
{
return true; // yes we need to be near a rock
}public override bool checkProceduralPrecondition (GameObject agent)
{
// find the nearest rock that we can mine
IronRockComponent[] rocks = FindObjectsOfType ( typeof(IronRockComponent) ) as IronRockComponent[];
IronRockComponent closest = null;
float closestDist = 0;foreach (IronRockComponent rock in rocks) {
if (closest == null) {
// first one, so choose it for now
closest = rock;
closestDist = (rock.gameObject.transform.position – agent.transform.position).magnitude;
} else {
// is this one closer than the last?
float dist = (rock.gameObject.transform.position – agent.transform.position).magnitude;
if (dist < closestDist) {
// we found a closer one, use it
closest = rock;
closestDist = dist;
}
}
}
targetRock = closest;
target = targetRock.gameObject;return closest != null;
}public override bool perform (GameObject agent)
{
if (startTime == 0)
startTime = Time.time;if (Time.time – startTime > miningDuration) {
// finished mining
BackpackComponent backpack = (BackpackComponent)agent.GetComponent(typeof(BackpackComponent));
backpack.numOre += 2;
mined = true;
ToolComponent tool = backpack.tool.GetComponent(typeof(ToolComponent)) as ToolComponent;
tool.use(0.5f);
if (tool.destroyed()) {
Destroy(backpack.tool);
backpack.tool = null;
}
}
return true;
}}
最大的行动部分是checkProceduralPreconditions方法。它是伴随着IronRockComponent在寻找最近的游戏对象，并保存这一目标演示。然后当它开始执行的时候，它将保存目标岩石并基于它去执行行动。当行动被再次使用时，它的所有领域都将被重置，从而让它们能够再次得到计算。
这是在Unity中添加到矿工实体对象的所有组件：
components(from gamedevelopment)
为了让你的代理能够运行，你必须添加如下组件：
GoapAgent。
执行IGoap的一种类别（也就是上述例子中的Miner.cs）
一些行动。
一个背包（只是因为行动在使用它；这与GOAP不相关）。
你可以添加自己想要的任何行动，这将改变代理的行为。你甚至可以提供给它所有的行动，从而让它可以挖矿石，锻造工具并砍伐树木。
每个劳工将走向他们需要行动的目标（树，岩石，砧板等待）去执行行动。铁匠将保持等待直至供应处出现铁矿石（来自矿工）。然后铁匠将去创造工具，并将工具放到离自己最近的供应处。当劳工的工具破损时，他们将前往铁匠附近的供应处获取新工具。
你可以在此获取新代码：http://github.com/sploreg/goap
结论
基于GOAP，你可以无需烦恼伴随着有限状态机出现的连通状态而创造出许多行动系列。你可以从代理手上添加或删除行动去创造出动态结果，同时也能够让你理智地维持代码的运行。你最终将获得一个灵活，机智且动态的AI。
（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）
