laya游戏开发之贪吃蛇大作战
一、背景二、引擎选择三、整体架构3.1 玩法分析3.2 游戏架构3.3 技术选型一、背景
需要快速实现一个贪吃蛇的 demo 以验证功能，非传统贪吃蛇玩法，是类似贪吃蛇大作战的多人联机玩法
二、引擎选择
引擎和语言的选择比较多样，但因为一开始的需求是H5或者微信小游戏的形式，因此没有考虑 Unity / UE4 等传统引擎（对 H5 的支持比较有限），转而考虑使用 cocos2d、laya 等原生支持 H5 的引擎 (引擎支持 JavaScript 开发)。
经过易用性、上手成本的考虑，最终决定用laya进行开发。laya 写一份代码可同时支持安卓/IOS/H5/微信小游戏，更满足当前开发时间有限、平台暂未确定的情况，用 JavaScript/TypeScript 开发也更容易上手。（注：并不是说 laya 就是最好的选择，日常开发还要考虑配套工具的完整性、平台迁移难度、社区活跃度等因素）
三、整体架构
接着是分析整个游戏的架构、确定技术选型等事项。
3.1 玩法分析
贪吃蛇大作战的玩法相对于传统贪吃蛇有一定不同，其核心玩法有其三：
通过吃掉食物来增加身体长度在有限的地图内规避其他玩家控制的贪吃蛇通过圈住或者拦截其他贪吃蛇，使其撞上自己或者墙壁导致死亡，其死亡后分数会转换为食物进行掉落
由以上三个核心玩法可以演变出许多进阶的游戏策略，但仅从实现上分析，游戏的核心玩法并不难：主要涉及到的局内功能点有蛇的角色控制和表现变化、多人游戏的碰撞和胜负结算、食物的随机生成等；局外系统也比较简单，包括排行榜、长度击杀数以及重开局等。
3.2 游戏架构
相对于传统单机游戏，贪吃蛇大作战涉及到了服务端开发，所以除了客户端功能的实现之外，需要同时考虑服务端的技术选型以及架构。
这里客户端选择了用 laya 引擎 js 语言去开发，服务端就选择了同一技术栈下的 nodejs 来开发，节约学习成本。
客户端简单的功能拆解如下：
（不是特别规范，请不要学习ToT）
服务端则比较复杂一些，因为涉及到多人游戏的同步问题（简单来说就是所有蛇在同一时间内在不同玩家的设备上表现一致，不会出现这边我移动了三格，那边我只移动了两格的情况），这里不过多讲解，可以看下这篇文章。
一般来说，网络同步有帧同步和状态同步两种方案，这两种方案并没有孰优孰劣之分，但有各自的应用场景。网上有大段的文章从同步效果、延时、可实现程度等方面去分析两者的区分，这里只对本项目进行分析：
从同步效果来说，状态同步负责同步状态(蛇的位置、食物的位置)，帧同步负责同步输入指令(玩家的移动指令)，可能存在的风险点是当地图很大食物很多时，食物的状态同步会有问题
从实现难度而言，状态同步所有计算都在服务器，帧同步在客户端，所以帧同步是需要一些特殊的实现去保证一致性的(比如伪随机和浮点数计算等) ，这些会在之后的文章里介绍
从重连和回放机制而言，帧同步易于实现，无非是重新计算一遍，而状态同步只能通过类似录像的形式
其实从实现成本而言，本应该用状态同步去做，但这个小 demo 有两个特殊需求：一个是必须要支持回放操作，而且是完完全全的复盘，这一点其实就相当于否决了状态同步了；另一个是严格同步，也就是每一帧各个设备的表现必须完全一致，而状态同步是允许一些误差的，因此最后还是选了帧同步。
3.3 技术选型
最终决定：
客户端这边开发语言 js，引擎选择 laya，通信协议用 protobuf
服务端选择 nodejs，语言 js，同步方式用帧同步，协议pb
PS: 之所以单独用一篇文章单独分析决定技术选型的过程，是因为笔者认为一个清晰的思路和合理的技术选型，可以缩减大半不必要的开发时间，哪怕是需要快速成型的小游戏，也同样如此
接下来还会用三到四篇文章讲解贪吃蛇大作战小游戏开发过程中客户端、服务端的主要代码框架，以及碰到的问题和解决方法等，欢迎关注！
如果觉得《laya游戏开发之贪吃蛇大作战（一）》对你有帮助，请点赞、收藏，并留下你的观点哦！
