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

　　由于我所在的手游项目上个月刚刚过审，因此大概有一点耳闻：自从广电总局发布新政以来，过审的大作不多，基本以休闲小游戏为主。因此《贪吃蛇大作战》的登顶，有时机好的因素在，档期好啊！
　　游戏本身其实规则非常简单，然而根据周围人的反应来看，大家对《贪吃蛇大作战》的沉迷程度比《球球大作战》要高。个人分析原因主要是：在《球球大作战》的游戏初期，玩家只能吃系统生成的点，并且游戏内永远是大吃小；而《贪吃蛇大作战》，一条刚出生的小蛇，也有可能直接吃掉大蛇，从而瞬间暴富。

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

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

　　这货居然是个单机。

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

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

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

　　1、基本数据初始化：

　　a)设置固定的几十个出生点（X1，Y1——Xn，Yn)，随机其中10个点（个数随便写的)，用于游戏开始时作为每条蛇的出生点；

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

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

　　d)设定蛇每吃6个小点，身体增加一个段；每吃1个大点（其他蛇的尸体)，身体增加一个段；

　　e)假设游戏逻辑帧为20帧，每0．05秒为一帧；以蛇身的每个点的1／10为一个基本长度单位（1米)，即每个大点为10米；

　　f)假设整个地图尺寸为10000＊10000（或者32767＊32767这种可能更利于程序运算的尺寸)；

　　g)假设从（0,0)看向（0,1)的角度为0°（0°就是360°)，逆时针增加（剑网三的引擎用的是比较麻烦的弧度，一圈为2π，tt)，用于进行一些角度计算，比如转向角度；

　　2、游戏开始，资源加载

　　a)由资源控制器随机生成1000个资源小点（1000这个数依然是我随便写的)，每个点的坐标（X，Y)，X和Y均进行random（1,10000或32768)随机；

　　b)在设置好的出生点中随机10个点，生成长度为5段的蛇，蛇头初始角度随机；

　　3、资源控制

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

　　4、蛇开始运动，执行本身的AI（由于我最擅长的AI是有限状态机而非行为树，因此用Xmind大概画了一下)

　　5、死亡处理

　　a)假设每条蛇死亡时，留下自己身体50％的资源作为尸体；（比如一个长度为100的蛇，死亡后会留下50个大点)

　　b)蛇死亡时，将自己身体的每个段的坐标点进行记录，放入一个table表中；

　　c)将table表中的坐标进行处理，每隔一个坐标删除一个，将t［1］，t［3］．．．．t［2ｎ－1］的坐标删除；

　　d)将保留的坐标放入一个新table表，定义为tleft；

　　e)在tleft的每个坐标点生成一个大尸体点；

　　备注1：

　　iOS版本中，每次复活的坐标点和初始角度都不一样；而安卓版本中，每次复活的坐标点和初始角度（0°)都相同；

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

　　备注2：

　　这里会有两种处理方式：

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

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

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

　　备注3：

　　转弯角度随机范围为（30,330)而非（0,360)，是为了避免180°调头的情况，因为这看上去比较奇怪。