问为什么命令设计模式对游戏AI有用？

EN

您说得对，这只是划分代码的另一种方式，而不是唯一的解决方案。

但是考虑一下，通常您希望您的ai代码生成一个命令列表，供参与者遵循。

1. 移动到x，
2. 接车，
3. 移到z，
4. 滴y

当第一个参与者移动到x时，ai可以循环通过被阻塞或已经完成其命令的其他参与者，为它们生成新的指令。

命令模式是一种很好(但不是唯一的)适合这种编程风格的模式。

Go4书中命令模式的意图部分如下：

将请求封装为对象，从而使您可以使用不同的请求、队列或日志请求参数化客户端，并支持可撤消的操作。

让我们分析一下其中的一些，并在游戏编程的背景下来看看它。

参数化调用代码

的能力

这允许您动态地配置调用命令的东西，并执行一个操作。这也可以通过回调来实现。命令对象可以在OO上替代您所需要的语言中的回调(例如，不支持高阶函数，也不支持闭包)；但是，如果以后需要访问或操作与命令相关的状态，或者支持更复杂的接口，那么只需执行()，拥有一个Command类就会有所帮助。

在本书中，在开发应用程序菜单框架时引入的模式，其中菜单项可以由命令进行配置。重要的一点是，菜单项不知道它做什么或者目标对象是什么--它不了解它执行的操作，它只是知道当单击它时应该发生一些事情。

您可以改变这个基本结构；例如，通过某种ID (并由其他组件获取)间接引用接收方my。

在游戏中，特别是在游戏AI中，一个非常类似的场景是，当您想要支持脚本时--命令可以封装用户提供的脚本(并且可能附带一些元数据，也可能是对脚本引擎的引用)。在这里，调用代码知道何时和在什么情况下执行脚本，但不知道要执行什么操作和影响哪些实体。(当然，还有其他方法)。这促进了所涉及的不同系统之间的关注点分离(AI，脚本编写)。

但也要考虑一些不那么异国情调的东西。键键。可能有多个键(或不同输入设备上的多个触发器)调用相同的操作，或者操作可能依赖于上下文(相同的键在不同的情况下做不同的事情)。此外，玩家可以在任何时候改变这些。处理此问题的一种方法是拥有一组命令对象，您可以将这些对象插入或插入到处理输入的系统中，并将它们与各种触发器动态关联。

对请求进行排队的能力

一旦你有了这个基础设施来映射输入到命令，你可以利用它在你的人工智能系统控制NPC。

现在，你说：

通常，在编写AI程序时，您希望指令立即执行。

嗯，他们不需要在做出决定的那一刻就被执行--就在游戏循环的当前周期内。此外，如果游戏使用ECS模式，命令流方法可能是一个很好的选择。此外，一些游戏运行他们的AI引擎在一个不同的更新速度，然后渲染器和其余的游戏，并排队AI输出作为命令可能是一个很好的方式来达到这一点。

对日志记录

的支持

这可能意味着真正的日志记录，但让我们再考虑一下。日志是记录的事件流。这可能会被(当构造的时候小心一些)，回放。回放和演示支持的盒子！添加一些计时元数据，并且经过一些努力，这还可以支持诸如时间倒带机制之类的东西，在这种情况下，玩家可以将时间倒转(直到某个点)再次尝试相同的场景(类似于在Braid或网格2中可能出现的情况)。

额外美食

支持撤销/重做的能力是非常不言自明的，所以我不会再讨论它。

您可以做的另一件有趣的事情是将它与复合模式结合起来，从而使您能够拥有由子命令组成的复合命令。对于开发人员来说，这可能只是一种方便，但也可以为构建编辑器提供支持，用户可以在GUI中构建这些复合命令，甚至可以将这些命令合并到游戏中，玩家可以在游戏中构建自定义行为，作为某种机制的一部分--并让游戏记住它们(因为您可以序列化和反序列化命令，包括复合命令)。

将命令作为对象或数据处理的另一个好处是，您可以灵活地并行执行其中的一些命令(如果任务是可并行的)，这可能会提高性能。

在这本书中，使用命令模式的主要动机首先是在引号之前解释一些段落，它是关于用户输入的，而不是AI。

我们可以使用同样的命令模式作为AI引擎和参与者之间的接口；AI代码只是发射命令对象。

当您“可以使用这个相同的命令模式作为AI引擎和参与者之间的接口”时，您应该已经使用这些命令来将用户的输入转换为游戏中的动作。否则，这句话甚至没有意义。

这里选择命令的AI和执行命令的参与者代码之间的解耦给了我们很大的灵活性。我们可以为不同的演员使用不同的人工智能模块。

也许你可以通过其他方式获得同样的好处，但是通过使用你已经拥有的东西，你可以免费获得它们。