跟着元气学编程【21】：阴间状态机的进一步实现

上一期已经定好这期的目标了：抽象条件类以及各种实现类。不多废话了，因为之前的20期已经把我所有的开场白用完了

各种实现类比较简单，毕竟父类已经定义好方法了，根据该种状态的实际情况去重写就行了

所有状态和条件的共同点：Init()方法中使用枚举标识自身的状态名/条件名。Action()为每个状态的应该被调用的行为，HandleTrigger()为每个条件检查的内容，一旦为True就切换状态

AttackingState：在当前状态下每隔一段特定时间攻击一次

DeadState：boss死亡后将状态机中的标记变为False

PatrollingState：沿着状态机中路点列表设定的路点前进

（这里按照路点列表原本的顺序前进，也可以换成随机的）

PursuitState：判断目标物体不为空时，朝着目标物体前进

好的现在到条件实现类了。因为各种条件内部仅仅只需判断布尔值，所以比状态实现类还要简单

CompletePatrolTrigger：判断是否完成巡逻（标识在状态机内部）

KilledPlayerTrigger：判断玩家的血量是否小于等于0（主要的变量也是在状态机里）

NoHealthTrigger：判断boss的血量是否小于等于0（需要的数据还是在状态机里）

ReachPlayerTrigger：判断玩家是否在boss的攻击范围里（所有的数据总是在状态机里）

TimeOutTrigger：boss追击一段时间就会切换为巡逻状态。故该条件判断是否达到指定时间（……永远在状态机里）

WithoutAttackingRangeTrigger：判断玩家是否超出boss的攻击范围（……反正就一样的意思，不想写了，虽然我发现现在好像写得更多了）

如果你看了一眼代码，你就会发现多了一个“Vector2”。这个类是我模仿Unity的API写的，用来处理二维向量的问题。本来想尝试把主要功能都写出来，但最后我发现我只需要得到两个点间的距离，所以就只有这个方法

（这么久了，我的雄心壮志全部都死在懒惰上🙁）

然后就到状态机本体了。可以发现有很多变量都会存储在状态机里。加上状态机还要负责各种状态的转换等乱七八糟的东西，所以内部就会显得杂乱无章，捋顺更是难上加难

所以就先把框架和部分方法实现出来吧！

（这只是变量）

（这才是方法。另外还没完）

（不过剩下的也不多了）

初始化所有状态及其转换条件时（ConfigFSM()方法）使用硬编码。虽然简单易懂，但是后期增加内容，状态/条件改变时都需要在代码内部更改，而且代码量过多。秉承代码最好“一劳永逸”的原则，最好使用上期提到的反射+配置文件

配置文件有txt，xml，json或者直接数据库。txt适合少量数据，往往会用特定的格式将数据写入txt文件，再根据这套格式写一个方法进行读取

（类似这样的txt文件）

xml比较灵活，存储较多的数据也不会特别吃力。就是数据一多，节点数也会爆炸式增长，基本上还需要另外写一个工具辅助记录

（长这样，我看不懂）

json我不是很懂，只知道可以用于本地和服务器交换数据。语法比较随意，但是数据量过多也不行

所以数据库yyds，无论多少直接存，表格的形式也方便同组不懂程序的人修改

但是无论怎样，游戏数据存在本地一定不是最安全的，都有被恶意篡改的风险。假如把数据存在服务器，每次打开游戏都是从服务器读取数据，这样无论有人在本地如何纂改文件，到时候都会被从服务器得到的数据二次覆盖，就比较安全了

🤔是不是跑题了？不过这期的内容也已经结束了，没有任何的测试，因为我根本就不敢运行这个状态机，怕改bug改到疯

另外关于配置文件的内容，可能不是特别准确，因为内容来自于2016年，我也不知道放到2021年是否适用

不对！！！2022年了！！！草，怎么这么快！！！先祝大家新年快乐，新的一年里每天都快快乐乐的，吃好睡好，学业或者事业上的问题都迎刃而解！

我实在想不出来什么高级的祝福词，就把一些基本的说了吧，土是土了点，不过有用就行

现在彻底结束了，这篇文章和2021年