贪吃蛇大作战 一场AI带来的胜利
《贪吃蛇大作战》近期成为了又一现象级游戏作品。由于我所在的手游项目上个月刚过审，所以有所了解：自广电总局发布新政以来，过审的大型游戏较少，主要以休闲小游戏为主。因此，《贪吃蛇大作战》能登顶，存在时机优势，档期较为有利。
游戏本身规则十分简单，但从周围人的反应来看，大家对《贪吃蛇大作战》的沉迷程度高于《球球大作战》。经个人分析，原因主要在于：《球球大作战》游戏初期，玩家只能吃系统生成的点，且游戏内始终是大吃小；而在《贪吃蛇大作战》中，刚出生的小蛇也有可能直接吃掉大蛇，实现瞬间“暴富”。
这种瞬间“暴富”的可能性，加剧了《贪吃蛇大作战》中对抗的激烈程度。同时，蛇死亡后在原地留下大量资源的设定，也直接增加了玩家之间互怼的可能性。所以，《贪吃蛇大作战》的对抗频率和刺激程度远超《球球大作战》。
然而，在玩了两三天后，我才发现这个游戏居然是单机的。其他玩家行为的一致性，以及断网、锁屏等情况下游戏仍可运行，都证明了这一点。这也解释了为何它能将多人即时PVP做得如此流畅，而《球球大作战》即便在延迟小于20ms的情况下，仍会让人明显感觉到卡顿。
下面我大概概括一下《贪吃蛇大作战》中蛇的AI和一些系统规则的基本实现思路，部分代码使用的是LUA：
1. 基本数据初始化
- 出生点设置：设置固定的几十个出生点（X1，Y1 —— Xn，Yn），随机选取其中10个点（该数量可根据实际情况调整），作为游戏开始时每条蛇的出生点。
- 复活点设置：在地图偏中心的位置，设置少于10个坐标点，作为蛇死亡之后的复活点。经测试，iOS版本与安卓版本在此处存在差异，各有利弊，具体在备注1中说明。
- 资源控制器设置：设置一个资源控制器，用于控制地图上资源的生成。
- 身体增长规则：设定蛇每吃6个小点，身体增加一个段；每吃1个大点（其他蛇的尸体），身体也增加一个段。
- 逻辑帧与长度单位：假设游戏逻辑帧为20帧，每0.05秒为一帧；以蛇身每个点的1/10为一个基本长度单位（1米），即每个大点为10米。
- 地图尺寸：假设整个地图尺寸为10000 10000（或者32767 32767这种可能更利于程序运算的尺寸）。
- 角度计算：假设从（0,0）看向（0,1）的角度为0°（0°等同于360°），逆时针角度增加（剑网三的引擎采用的是较为复杂的弧度制，一圈为2π），用于进行一些角度计算，如转向角度。
2. 游戏开始，资源加载
- 资源小点生成：由资源控制器随机生成1000个资源小点（该数量可根据实际情况调整），每个点的坐标（X，Y），X和Y均通过random（1,10000或32768）随机生成。
- 蛇的生成：在设置好的出生点中随机选取10个点，生成长度为5段的蛇，蛇头初始角度随机。
3. 资源控制
资源控制器需要每隔一段时间（例如0.5s）对场上所有资源（小点 + 大点）进行统计，同时补充小点资源，默认每次补充5个（该数量可根据每条蛇每秒吃掉1个小点的速度进行调整）。当大点数量较多时，小点的生成速度降低。
4. 蛇开始运动，执行本身的AI
（由于我最擅长的AI是有限状态机而非行为树，因此用Xmind大概绘制了一下相关逻辑）
5. 死亡处理
- 资源留存：假设每条蛇死亡时，留下自己身体50％的资源作为尸体。例如，一条长度为100的蛇，死亡后会留下50个大点。
- 坐标记录：蛇死亡时，将自己身体每个段的坐标点进行记录，放入一个table表中。
- 坐标处理：对table表中的坐标进行处理，每隔一个坐标删除一个，即删除t［1］，t［3］……t［2n - 1］的坐标。
- 新表定义：将保留的坐标放入一个新table表，定义为tleft。
- 大尸体点生成：在tleft的每个坐标点生成一个大尸体点。
备注1
iOS版本中，每次复活的坐标点和初始角度都不一样；而安卓版本中，每次复活的坐标点和初始角度（0°）都相同。iOS版本的优势在于随机性可带来一定变化，但缺点是存在蛇出生在地图边缘，玩家来不及反应就直接撞墙的可能性；安卓版本的好处是避免了出生就撞墙的可能，但可能会让玩家直接复活在其他蛇的包围之中。
备注2
这里有两种处理方式：
- 方式一：10个蛇头，每个蛇头循环遍历场上所有小点资源的坐标（可采用将全场地分成若干个大区域块的方式，缩小遍历范围，提高效率），判断是否已吃掉。
- 方式二：场地中所有的大、小点资源，每个都循环遍历场上所有蛇头的坐标，判断是否已被吃掉。
这两种方式每次遍历的次数看似都是“蛇头数 * 资源数”，但我不确定哪一种运行效率更高。
备注3
转弯角度随机范围设定为（30,330）而非（0,360），是为了避免180°调头的情况，因为这种情况看上去比较奇怪。