《贪吃蛇大作战》，一场AI带来的胜利？

　《贪吃蛇大作战》，应该是最近的又一个现象级作品了。

　　由于我所在的手游项目上个月刚刚过审，因此大概有一点耳闻：自从广电总局发布新政以来，过审的大作不多，基本以休闲小游戏为主。因此《贪吃蛇大作战》的登顶，有时机好的因素在，档期好啊！

　　游戏本身其实规则非常简单，然而根据周围人的反应来看，大家对《贪吃蛇大作战》的沉迷程度比《球球大作战》要高。个人分析原因主要是：在《球球大作战》的游戏初期，玩家只能吃系统生成的点，并且游戏内永远是大吃小；而《贪吃蛇大作战》，一条刚出生的小蛇，也有可能直接吃掉大蛇，从而瞬间暴富。

　　就是这种瞬间暴富的可能性，加大了《贪吃蛇大作战》中对抗的激烈程度。同时，蛇死亡后在原地留下大量资源的设定，更是直接增加了互怼的可能性。因此《贪吃蛇大作战》的对抗程度，远比《球球大作战》更频繁、更刺激。

　　然而在我中毒两三天以后，才发现：

　　这货居然是个单机。

　　其他玩家行为的一致性，加上断网、锁屏等情况下的运行情况，无疑证明了这一点。

　　我说怎么他们把多人即时ＰＶＰ做得如此流畅，而《球球大作战》即使是在＜20ms延迟的情况下，也依然会让人感觉到明显的卡顿。

　　我大概概括了一下《贪吃蛇大作战》中蛇的ＡＩ和一些系统规则的基本实现思路，部分代码用的是ＬＵＡ：

1、基本数据初始化：

　　ａ）设置固定的几十个出生点（Ｘ１，Ｙ１——Ｘｎ，Ｙｎ），随机其中１０个点（个数随便写的），用于游戏开始时作为每条蛇的出生点；

　　ｂ）在地图偏中心的位置，设置＜１０个坐标点，作为蛇死亡之后的复活点（经测试，ｉＯＳ版本与安卓版本此处有差异，各有利弊，后面的备注１细说）；

　　ｃ）设置一个资源控制器，用于进行地图上资源生成的控制；

　　ｄ）设定蛇每吃６个小点，身体增加一个段；每吃１个大点（其他蛇的尸体），身体增加一个段；

　　ｅ）假设游戏逻辑帧为２０帧，每０．０５秒为一帧；以蛇身的每个点的１／１０为一个基本长度单位（１米），即每个大点为１０米；

　　ｆ）假设整个地图尺寸为１００００＊１００００（或者３２７６７＊３２７６７这种可能更利于程序运算的尺寸）；

　　ｇ）假设从（０,０）看向（０,１）的角度为０°（０°就是３６０°），逆时针增加（剑网三的引擎用的是比较麻烦的弧度，一圈为２π，ＴＴ），用于进行一些角度计算，比如转向角度；

2、游戏开始，资源加载

　　ａ）由资源控制器随机生成１０００个资源小点（1000这个数依然是我随便写的），每个点的坐标（Ｘ，Ｙ），Ｘ和Ｙ均进行random（1,10000或32768）随机；

　　ｂ）在设置好的出生点中随机１０个点，生成长度为５段的蛇，蛇头初始角度随机；

３、资源控制

　　资源控制器需要每隔一段时间（比如０．５ｓ）进行一次场上所有资源的总和（小点＋大点），同时进行一次小点资源的补充，默认每次５个（瞎拍的，按每条蛇每秒吃掉１个小点计算）。大点比较多时，小点的生成速度降低。

４、蛇开始运动，执行本身的ＡＩ（由于我最擅长的ＡＩ是有限状态机而非行为树，因此用ｘｍｉｎｄ大概画了一下）

　　ａ）假设每条蛇死亡时，留下自己身体５０％的资源作为尸体；（比如一个长度为１００的蛇，死亡后会留下５０个大点）

　　ｂ）蛇死亡时，将自己身体的每个段的坐标点进行记录，放入一个ｔａｂｌｅ表中；

　　ｃ）将ｔａｂｌｅ表中的坐标进行处理，每隔一个坐标删除一个，将ｔ［１］，ｔ［３］．．．．ｔ［２ｎ－１］的坐标删除；

　　ｄ）将保留的坐标放入一个新ｔａｂｌｅ表，定义为ｔＬＥＦＴ；

　　ｅ）在ｔＬＥＦＴ的每个坐标点生成一个大尸体点；

——————————————————————————————————————

备注１：

　　ｉＯＳ版本中，每次复活的坐标点和初始角度都不一样；而安卓版本中，每次复活的坐标点和初始角度（０°）都相同；

　　ｉＯＳ版本的好处是，随机性可以带来一定的变化，但坏处是，存在出生在地图边缘并且在玩家反应不及的情况下直接撞墙的可能性；而安卓版本的好处是，避免了出生就撞墙的可能，但是可能会让玩家直接复活在其他蛇的包围之中……

备注２：

　　这里会有两种处理方式：

　　１、１０个蛇头，每个蛇头循环遍历场上所有小点资源的坐标（当然可以采用将全场地分成若干个大区域块的方式，将遍历的范围缩小，提高效率），判断是否已吃掉；

　　２、场地中所有的大、小点资源，每个都循环遍历场上所有蛇头的坐标，判断是否已被吃掉；

　　这两种方式看上去每次遍历的次数好像都是“蛇头数＊资源数”，我不确定哪一种的运行效率会更高。

备注３：

　转弯角度随机范围为（３０,３３０）而非（０,３６０），是为了避免１８０°调头的情况，因为这看上去比较奇怪。