无尽扫雷-从开发到挂起

0. 起止时间:

2017年11月11日 立项
2018年4月27日 挂起
游戏只上架成功了Google Play地址 

1. 起因:

那是双十一很偶然的一天, 在youtube上看到一个视频. 说的是一款网页版本的扫雷游戏. 竟然是没有边界的, 可以让全球人一起玩的那种. http://mienfield.com/ ps: 这个网站差不多1月的时候也挂了.
现在还能看看视频

当时觉得这个创意好酷, 再到google play和app store上搜索了一下. 竟然没有任何一款无尽版本. ok! 立项!

2. 开发过程:

2.1 确定实现方式

选择go和cocos creator作为双端实现方案, 并初步学习差不多用了1个月.(2017年11月-12月).
一开始打算用熟悉的C++来做双端, 毕竟和之前挂机游戏一脉相承. 不过考虑想顺便学点新东西, 服务端采用了Golang实现的leaf框架制作, 客户端采用Creator的TS来写.

2.2 密集开发

密集开发游戏功能(2017年12月-2018年2月春节前夕)
实际做起来还是发现不少挺费事的地方, 但是担心如果大规模数据进来, 游戏服要能动态扩展. 就写成了无状态可分布式游戏服+redis缓存+mysql最终持久化.
而客户端也经历了好多次性能优化, 才打到了满意的效果. 毕竟同时加载近2000个节点. 还需要绘制小地图.
最终, 客户端代码+服务端代码一共差不多2W行的样子. 边陪闺女边做差不多3个月.

2.3 提交

对接与提审(2018年3月-4月底)
对接的时候Google的麻烦多, 调试起来必须非大陆账号才能正常内购, 最后还是买的礼品卡解决的真实环境测试.
提审的时候就是苹果的蛋疼了. 尝试了大半个月都被打回了. 最后两次一次判定
Guideline 4.3 - Design 说是spam经过解释后判定Guideline 4.1 - Design - Copycats
只能暂时搁置了.

3. 挂起

终归还是上线成功了google play, 还是凭借前些时阿里云的便宜服务器, 购买了3年的. 全部都部署好了. 如果你有兴趣可以来试试.

扫雷小地图优化之矩形合并

扫雷的小地图是一个动态的点阵图, 直接使用Graphics组件绘制在大屏幕绘制大概64x64空间时, 按每个数据点进行绘制时性能还算面前能够接受, 大概10几个毫秒
但是到了丧心病狂的滚动大地图时, 因为有256x256的数据, 这个数量级如果还是俺点绘制. 6万5的数据点, 每个点还都是矩形, 我的妈妈咪呀, 几十万的GL vert爽的不要不要的
所以我们要将相同的数据举行进行合并, 合并时算法还要带剪枝, 要不性能又都跑到脚本层消耗掉了.
一开始是两道循环, 用Map保存数据(是为了查找方便)
到最后是一道循环加内嵌的一道高度剪枝的循环, 数据全部用Array, 终于算是手机上效率可以接受了. 大概200毫秒左右, 90%多的性能消耗还是最后落在了Graphics的fillRect上面
用两张图简单表示一下大概意思, 黑灰的为正常显示, 彩色的是我将每个矩形都随机了RGB颜色, 希望能看明白.

CocosCreator多节点优化杂谈

无尽扫雷大多数功能都已做完，进行性能调优。本以为只要用了缓存池就不会存在过多问题，哪知道不卡只是桌面浏览器WebGL里的事情。
直接说结论，调试的血泪史就不扯淡了。

• 预制首先还是要全部由NodePool进行缓存，缓存在加载场景时逐步加载。
• 扫雷节点，替换资源时，直接用loadRes效率还是不足，把通用的spriteFrame缓存，改扫雷资源的时候直接等于上去会快很多
• 尽量避免大规模js与原生层通信频率，1200多个节点一起setPosition在move事件不可取。要直接移动他们的父节点
• 由于扫雷一共管理1200多个扫雷节点，如果只用NodePool还是有轻微卡顿，修改节点的parent还是需要一定时间的。如果能把要删除的节点直接改个资源换个坐标，效率比NodePool高。
• label的非fnt字体，描边，节点的mask都会打断渲染批次。能不用就不用，不过这个对于扫雷这种素材不多的游戏来说都还好。直接用碎图然后用自动图集就可以自动合并渲染批次。

好了，差不多就这么些。通过这些细节处理，基本达到了流畅扫雷目的。至少在骁龙626上是这样。

Hello World, again!

时隔数年, BaihowFF.com又重新回来了.
虽然blog越来越边缘化了, 还是以此blog记录一些所思所想