前言
上半年要做一款实时竞速类微信小游戏.要求操控流畅且碰撞交互模拟物理世界的真实效果.之后开始预研游戏帧同步服务和支持跨平台物理引擎.这期间预研并测试了许多方案.最终才得出最终的游戏实现方案
预研
预研大概经历了四个过程:
1.物理引擎
斥资购买论坛某位研发同学的物理引擎与帧同步游戏实现方案.了解了帧同步和物理引擎以及游戏整个生命周期如何保持同步.并了解了此类游戏开发的注意事项
2.帧同步服务
考虑后台研发和维护成本初步选型了微信的帧同步游戏服务.学习并参考官方的帧同步项目
3.初步测试
根据第一步中的整体框架方案和第二步中的帧同步项目开始实现自己游戏的核心竞速功能.不过实际结果是稳定的.论坛上的帧同步游戏实现方案选型的物理引擎是Box2D和自身搭建的帧同步服务器.由于Box2D本身并不是确定性物理引擎.是不能满足跨平台物理同步的.就算适配了三角函数仍然有问题.我测试期间发现比较明显的情况就是多个刚体之间发生碰撞的时候很大概率就出现不同步的问题.尤其是碰撞区域很小的时候不同步情况会很明显.另外玩家自身搭建的服务器不稳定给测试造成了很大的问题.最终放弃了Box2D物理引擎.复盘的时候想想一开始就不应该选择一个不确定性物理引擎.引擎做不到就是做不到.强扭的瓜不是很甜.不过帧同步服务选择微信的确定是没有问题的.最重要的问题每帧同步需要服务端处理的逻辑应该怎么处理
4.预研结果
长痛不如短痛.所以不再考虑CocosCreator中自带的物理引擎.而且我比较倾向与TS研发.所以最终选择了Rapier引擎.这是一个确定性的物理引擎.能满足我前面的要求.不过老外的东西一个是维护不及时.另外就是参考文档少.不过这些不是重点.重点微信开发者功能和Web上可以通过插件的形式加载Rapier.但是在真机上中是不可以的.因为微信API封装了WebAssembly.使用自己的WXWebAssembly它限制游戏只能加载本地的.wasm.这就会出现更多的问题.Rapier打包之后的.wasm达到了1M左右.这样游戏基本废了.随便一搞就超过了首包4M.
办法总比困难多.j经过研究发现微信支持加载wasm的压缩格式wasm.br.压缩之后300K左右.满足了需求.不过问题又来了微信中直接加载wasm本地文件会出现WebAssembly.instantiate加载异常.经过查找定位问题最终这个异常只能通过修改源码解决.到此为止微信帧同步和物理引擎都已定型并可以正常运行了.之后便可进入具体调研阶段
调研
1.物理引擎控件封装
由于官方对内置的物理引擎封装了Collider和Shape和Body等插件使用起来也比较方便.我做的游戏需要大量刚体.所以封装成类似的控件会一劳永逸.之后便封装了RapierCollider和RapierShape和RapierBody和RapierDebug.不过测试这些Rapier物理控件引擎期间遇到许多使用的坑和问题.好在都一一解决了.有了这些控件再添加一个RapierManager单例整体控制物理引擎与游戏的交互.
2.帧同步服务
官方的帧同步项目只是简单的发射子弹游戏很简陋.完全是代码的堆叠.复用基本不可能.我的游戏数据交互比较复杂而且功能比较多.索性架构一个帧同步模块.这样其它游戏复用也就简单了
3.游戏同步与帧同步和物理同步
搞定物理引擎和帧同步封装之后下面就是与游戏逻辑同步的问题了.这其中的注意事项很多很多.列出比较重要的几点:
(1)帧同步控制所有客户端逻辑
(2)客户端所有的不稳定因素不能控制逻辑.比如通过动画的开始与结束控制客户端逻辑.不能使用系统的随机函数等
(3)物理引擎的同步时机
(4)应该放到服务端处理的玩家交互逻辑如何处理
等等
研发
搞定调研的问题之后就剩下业务逻辑开发了.下面是1.0版本的功能图谱:
发布
对物理引擎帧同步游戏感兴趣的 或者对养成了游戏感兴趣的可以体验下线上版本.欢迎各位指指点点.有什么问题可以私信或者留言交流
