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