我的游戏开发的第一阶段是RTS引擎的开发。 我打算在此博客上撰写一系列有关已出现的问题及其解决方案的文章。 在这篇文章中，我将告诉您如何组织单位的行为。
考虑到一般从何处启动此RTS引擎，我得出的结论是，值得从细节入手，并从其过渡到抽象。 我想到的第一个应用程序是资源的收集，或者说是木材的提取。
通常，在大多数策略中，此过程都包含以下事实：员工在接到砍伐树木的命令后，便去了树，并用斧头挥舞镐在他附近挥舞了一段时间，然后去了仓库并重新开始。
也就是说，该过程如下所示：
因此，该图片可以真正声明自动机的名称，它缺少状态与初始状态和最终状态之间转换的条件。
这里的一切都很简单：机器被初始化为“我要砍”状态，工作的结束发生在更改期间。 我们可以使用以下条件表示状态之间的转换：“到达树上”，“砍掉一堆柴火”，“到达仓库”，“交出资源”。 如果答案为是，则机器进入下一个状态；如果答案为否，则机器保持当前状态。
在自动机的每个状态下，在迭代过程中都会调用相应的动作。 在状态之间的过渡期间也可以执行一组动作。
例如，在“移交”状态下进行迭代时，单位背包中的资源将被转移到玩家的资源库中，而当从“准备砍伐”状态切换到“卢布”状态时，相应的动画将开始。
我还注意到，行走本身不是“原子”操作，它在许多行为中都发现并且本身就是一种行为，因此，树提取行为实际上是在内部行走时使用的行为。 也就是说，可以使用其他几个有限自动机的组合来获得新的自动机。
通过以这种方式编写行为，我们在行为实现的细节与管理这些行为的高级策略之间获得了架构上的界限。 行为的实现本质上成为游戏其余部分的插件，也就是说，行为的更改不会影响高级逻辑工作的正确性。
这些行为通过调用Unit类型的对象的Update事件的迭代方法来起作用（此事件在每一帧触发）。 为了与世界其他地方进行通信，将调用IStateMachineListener方法。
这是我的游戏中状态机构造的一个示例。 收到施工团队后，单位将到达指定地点，然后进入直接施工状态，将建筑单位转移到建筑物。 当建筑物中积累了足够的建筑单位时，建筑机械将结束，并且该单位将收到新的行为，即默认行为。
仅此而已。 如果您喜欢或不喜欢这种格式，请在评论中写出来！